PostgreSQL后端进程内存占用过高问题

Question

我们正在评估使用 PostgreSQL 来实现多租户数据库， 目前我们正在对单数据库多模式模型进行一些测试 （基本上，所有租户在同一数据库中的自己的模式下都具有相同的数据库对象集）。 应用程序将维护一个在所有租户/模式之间共享的连接池。

例如，如果数据库有 500 个租户/模式，每个租户有 200 个表/视图， 表/视图的总数将为 500 * 200 = 100,000。

由于连接池将被所有租户使用，最终每个连接都会命中所有表/视图。

在我们的测试中，当连接访问更多视图时，我们发现后端进程的内存使用量增加得相当快，并且大部分都是私有内存。 这些内存将一直保留到连接关闭为止。

我们有一个测试用例，一个后端进程使用超过 30GB 内存，最终出现内存不足错误。

为了帮助理解这个问题，我编写了代码来创建简化的测试用例 - MTDB_destroy：用于清除租户模式 - MTDB_Initialize：用于创建多租户数据库 - MTDB_RunTests：简化的测试用例，基本上从所有租户视图中一一选择。

我所做的测试是在 CentOS 5.4 上的 PostgreSQL 9.0.3 上进行的。

为了确保我有一个干净的环境，我重新创建了数据库集群并将大部分配置保留为默认值， （我唯一需要改变的是增加“max_locks_per_transaction”，因为 MTDB_destroy 需要删除许多对象。）

这就是我重现问题的方法：

1. 创建一个新数据库，
2. 使用附加的代码创建三个函数

3. connect to新创建的数据库并运行初始化脚本

   --初始化

   选择 MTDB_Initialize('租户', 100, 100, true);

   -- 不确定真空分析在这里是否有用，我只是运行它

   真空分析；

   --检查创建的表/视图

   select table_schema, table_type, count(*) from information_schema.tables where table_schema like 'tenant%' group by table_schema, table_type order by table_schema, table_type;

4. 打开与新创建的数据库的另一个连接并运行测试脚本

   --获取当前连接的后端进程ID

   选择 pg_backend_pid();

   -- 打开 Linux 控制台并运行 ps -p 并观察 VIRT、RES 和 SHR

   --运行测试

   select MTDB_RunTests('tenant', 1);

观察：

1. 首次创建用于运行测试的连接时，

   VIRT = 182MB，RES = 6240K，SHR=4648K

2. 运行测试一次后，（花了175 秒）

   VIRT = 1661MB RES = 1.5GB SHR = 55MB

3. 再次重新运行测试（耗时 167 秒）秒）

   VIRT = 1661MB RES = 1.5GB SHR = 55MB

4. 再次重新运行测试（耗时 165 秒）秒）

   VIRT = 1661MB RES = 1.5GB SHR = 55MB

因为我们扩大了表的数量、内存使用量在测试中也取得进步。

谁能帮忙解释一下这里发生了什么？ 有没有办法可以控制 PostgreSQL 后端进程的内存使用情况？

谢谢。

塞缪尔

-- MTDB_destroy
create or replace function MTDB_destroy (schemaNamePrefix varchar(100))
returns int as $$
declare
   curs1 cursor(prefix varchar) is select schema_name from information_schema.schemata where schema_name like prefix || '%';
   schemaName varchar(100);
   count integer;
begin
   count := 0;
   open curs1(schemaNamePrefix);
   loop
      fetch curs1 into schemaName;
      if not found then exit; end if;           
      count := count + 1;
      execute 'drop schema ' || schemaName || ' cascade;';
   end loop;  
   close curs1;
   return count;
end $$ language plpgsql;

-- MTDB_Initialize
create or replace function MTDB_Initialize (schemaNamePrefix varchar(100), numberOfSchemas integer, numberOfTablesPerSchema integer, createViewForEachTable boolean)
returns integer as $$
declare   
   currentSchemaId integer;
   currentTableId integer;
   currentSchemaName varchar(100);
   currentTableName varchar(100);
   currentViewName varchar(100);
   count integer;
begin
   -- clear
   perform MTDB_Destroy(schemaNamePrefix);

   count := 0;
   currentSchemaId := 1;
   loop
      currentSchemaName := schemaNamePrefix || ltrim(currentSchemaId::varchar(10));
      execute 'create schema ' || currentSchemaName;

      currentTableId := 1;
      loop
         currentTableName := currentSchemaName || '.' || 'table' || ltrim(currentTableId::varchar(10));
         execute 'create table ' || currentTableName || ' (f1 integer, f2 integer, f3 varchar(100), f4 varchar(100), f5 varchar(100), f6 varchar(100), f7 boolean, f8 boolean, f9 integer, f10 integer)';
         if (createViewForEachTable = true) then
            currentViewName := currentSchemaName || '.' || 'view' || ltrim(currentTableId::varchar(10));
            execute 'create view ' || currentViewName || ' as ' ||
                     'select t1.* from ' || currentTableName || ' t1 ' ||
             ' inner join ' || currentTableName || ' t2 on (t1.f1 = t2.f1) ' ||
             ' inner join ' || currentTableName || ' t3 on (t2.f2 = t3.f2) ' ||
             ' inner join ' || currentTableName || ' t4 on (t3.f3 = t4.f3) ' ||
             ' inner join ' || currentTableName || ' t5 on (t4.f4 = t5.f4) ' ||
             ' inner join ' || currentTableName || ' t6 on (t5.f5 = t6.f5) ' ||
             ' inner join ' || currentTableName || ' t7 on (t6.f6 = t7.f6) ' ||
             ' inner join ' || currentTableName || ' t8 on (t7.f7 = t8.f7) ' ||
             ' inner join ' || currentTableName || ' t9 on (t8.f8 = t9.f8) ' ||
             ' inner join ' || currentTableName || ' t10 on (t9.f9 = t10.f9) ';                    
         end if;
         currentTableId := currentTableId + 1;
         count := count + 1;
         if (currentTableId > numberOfTablesPerSchema) then exit; end if;
      end loop;   

      currentSchemaId := currentSchemaId + 1;
      if (currentSchemaId > numberOfSchemas) then exit; end if;     
   end loop;
   return count;
END $$ language plpgsql;

-- MTDB_RunTests
create or replace function MTDB_RunTests(schemaNamePrefix varchar(100), rounds integer)
returns integer as $$
declare
   curs1 cursor(prefix varchar) is select table_schema || '.' || table_name from information_schema.tables where table_schema like prefix || '%' and table_type = 'VIEW';
   currentViewName varchar(100);
   count integer;
begin
   count := 0;
   loop
      rounds := rounds - 1;
      if (rounds < 0) then exit; end if;

      open curs1(schemaNamePrefix);
      loop
         fetch curs1 into currentViewName;
         if not found then exit; end if;
         execute 'select * from ' || currentViewName;
         count := count + 1;
      end loop;
      close curs1;
   end loop;
   return count;  
end $$ language plpgsql;

Answer 1

这些连接是在事务中空闲还是只是空闲？听起来好像未完成的事务正在占用内存，或者可能存在内存泄漏或其他问题。

Answer 2

对于在搜索时看到此线程的人（就像我所做的那样），我发现在不同的上下文中似乎存在相同的问题。空闲进程慢慢地消耗越来越多的内存，直到 OOM 杀手将它们取出（导致周期性的数据库崩溃）。

我们将问题追溯到长时间运行的 PHP 脚本，该脚本使一个连接长时间保持打开状态。我们能够通过定期关闭连接并重新连接来控制内存。

从我读到的内容来看，postgres 做了很多缓存，所以如果你有一个会话访问很多不同的表/查询，那么这个缓存数据可以继续增长。

-肯