平安科技PostgreSQL案例分享|进程私有内存探密__近期遇到一个案例，一个分析型应用的DB在早上的时候出现OOM，OS kill用户进程，数据库进入recovery，几十秒后数据库恢复。: 世界上功能最强大的开源数据库...

.blue {
    color: blue;
  }

.yellow {
    background-color: yellow;
  }

.green {
    background-color: green;
  }

.skyblue {
    background-color: skyblue;
  }

pre {
 white-space: pre-wrap;
 word-wrap: break-word;
 }
</style>

## 作者介绍

**石勇虎**，平安科技资深数据库工程师，多年PostgreSQL数据库相关开发运维经验。2016年加入平安，一直致力于PostgreSQL数据库运维管理工作。对其他数据库产品也有一定的涉猎。

**背景介绍**

近期遇到一个案例，一个分析型应用的DB在早上的时候出现OOM，OS kill用户进程，数据库进入recovery，几十秒后数据库恢复。OS报错如下：

<pre>
1. # cat /var/log/messages | grep -i "out of memory"
2. 07:08:48 cnlf081173 kernel: Out of memory: Kill process 15095 (postgres) score 155 or sacrifice chil
</pre>

数据库报错如下：

<pre>
3. 07:08:49.663 CST,,,21174,,5c29bb9e.52b6,23,,2018-12-31 14:47:58 CST,,0,LOG,00000,"server process (PID 15095) was terminated by signal 9: Killed","Failed process was running: SELECT appid, device_type, c_type, c_name, nc_name, status FROM tbl_app_os_ver_channel WHERE appid in …
</pre>

需要说明的是，发生问题DB是目前平安较大的PG单实例数据库，数据量将近30TB，目前每天增量为100GB，数据库负载较高，有使用到大量`pg_pathman`分区。

我们知道linux下，当主机物理内存和swap空间都用尽时才会引发OOM，那么是什么操作会使用大量的内存，导致内存不足呢？通过排查对应时间点top sql，尤其是上面报错涉及的sql，发现并未涉及大量的分组排序等操作。我们也排查了数据库内存参数，比如`shared_buffers`,`work_mem`, `max_connections`等，还有 os内核参数，是否关闭numa等，发现都是在合理的范围内。

## 原因分析

在分析原因之前我们先来了解下pg的内存架构：

![](/images/news/2019/20190319_0826_01.png =600x509)

PG的内存管理主要是共享内存和内存上下文MemoryContext。共享内存是在数据库启动时根据各相关参数计算好的固定大小，而内存上下文则是根据进程的实际使用情况来分配的。进程的私有内存也由内存上下文来管理。

经过排查发现该数据库为独占主机，随着业务增长，内存使用率也有增长，保持在70%多，而且内存使用率高并不是个别进程使用大量内存导致的，随便一个简单的查询（不涉及排序等）都会使用500多MB的私有内存空间，如果不通过pgbouncer连接，执行时间也要8s左右，我们怀疑还是这个库数据字典过大的原因。

<pre>
1. psql (9.5.5)
2. # select pid from pg_stat_activity where query=current_query();
3. pid
4. ------
5. 2033
6. (1 row)
7. Time: 8246.251 ms
</pre>

pmap查看进程的私有内存大小，达到580多MB。

<pre>
1. $ pmap -d 2033
2. 2033: postgres: eits: postgres eits [local] idle
3. Address Kbytes Mode Offset Device Mapping
4. mapped: 43811596K writeable/private: 585464K shared: 43100280K
</pre>

`pg_class`有170w+个对象。

<pre>
1. # select count(1) from pg_class;
2. count
3. ---------
4. 1713920
5. (1 row)
</pre>

我们在测试环境进行了模拟，通过`pg_pathman`对单表创建10w个分区，问题重现

<pre>
1. create table tt_pathmantest2(like tt);
2. SELECT create_range_partitions('tt_pathmantest2', 'id', '0'::bigint, '100'::bigint,100000);
</pre>

查看单个进程的私有内存使用大小

用gdb dump查看进程私有内存中存放的内容，发现基本上都是pathman的配置信息,

<pre>
6. $ cat /proc/20213/maps
7. 00400000-009aa000 r-xp 00000000 fd:06 43141376 /paic/postgres/base/9.5.5/bin/postgres
8. 00ba9000-00baa000 r--p 005a9000 fd:06 43141376 /paic/postgres/base/9.5.5/bin/postgres
9. 00baa000-00bb6000 rw-p 005aa000 fd:06 43141376 /paic/postgres/base/9.5.5/bin/postgres
10. 00bb6000-00c00000 rw-p 00000000 00:00 0
11. 02a8c000-02ad1000 rw-p 00000000 00:00 0 [heap]
12. 02ad1000-03d69000 rw-p 00000000 00:00 0 [heap]
13. 2ae1bfd62000-2ae1bfd83000 r-xp 00000000 fd:00 67334359 /usr/lib64/ld-2.17.so
14. 2ae1c77ac000-2ae1c77d6000 r-xp 00000000 fd:06 67150233 /paic/postgres/base/9.5.5/lib/pg_pathman.so
15. 2ae1c77d6000-2ae1c79d5000 ---p 0002a000 fd:06 67150233 /paic/postgres/base/9.5.5/lib/pg_pathman.so
16. 2ae1c79d5000-2ae1c79d7000 rw-p 00029000 fd:06 67150233 /paic/postgres/base/9.5.5/lib/pg_pathman.so
17. 2ae1c79d7000-2aeeaf0cf000 rw-s 00000000 00:04 55482843 /dev/zero (deleted)
18. 2aeeaf0cf000-2aeeaf0db000 r-xp 00000000 fd:00 69271978 /usr/lib64/libnss_files-2.17.so
19. 2aeeaf0db000-2aeeaf2da000 ---p 0000c000 fd:00 69271978 /usr/lib64/libnss_files-2.17.so
20. 2aeeaf2da000-2aeeaf2db000 r--p 0000b000 fd:00 69271978 /usr/lib64/libnss_files-2.17.so
21. 2aeeaf2db000-2aeeaf2dc000 rw-p 0000c000 fd:00 69271978 /usr/lib64/libnss_files-2.17.so
22. … …
23. 2aeeaf2dc000-2aeeaf2e2000 rw-p 00000000 00:00 0
24. 2aeeaf344000-2aeeafc8b000 rw-p 00000000 00:00 0 -- 内存大小计算方法c8b000-344000=947000(H)=9728000(D)=9MB
25. 2aeeafccc000-2aeeb06ce000 rw-p 00000000 00:00 0
26. 2aeeb074f000-2aeeb3827000 rw-p 00000000 00:00 0
27. 2aeeb472b000-2aeeb4f2c000 rw-p 00000000 00:00 0
28. 2aeeb572d000-2aeeb672f000 rw-p 00000000 00:00 0
29. 2aeeb6f30000-2aeeb7731000 rw-p 00000000 00:00 0
30. 2aeeb7f32000-2aeeb8733000 rw-p 00000000 00:00 0
31. 2aeeb8f34000-2aeeb9f36000 rw-p 00000000 00:00 0
32. 2aeeba737000-2aeebaf38000 rw-p 00000000 00:00 0
33. 2aeebb739000-2aeebbf3a000 rw-p 00000000 00:00 0
34. 2aeebc73b000-2aeebcf3c000 rw-p 00000000 00:00 0
35. 2aeebd73d000-2aeebe73f000 rw-p 00000000 00:00 0
36. 2aeebef40000-2aeebf741000 rw-p 00000000 00:00 0
37. 2aeebff42000-2aeec0743000 rw-p 00000000 00:00 0
38. 2aeec0f44000-2aeec1f46000 rw-p 00000000 00:00 0
39. 2aeec2747000-2aeec2f48000 rw-p 00000000 00:00 0
40. 2aeec3749000-2aeec3f4a000 rw-p 00000000 00:00 0
41. 2aeec474b000-2aeec584e000 rw-p 00000000 00:00 0
42. 2aeec604f000-2aeec6850000 rw-p 00000000 00:00 0
43. 2aeec7051000-2aeec7852000 rw-p 00000000 00:00 0
44. 2aeec8053000-2aeec9055000 rw-p 00000000 00:00 0
45. 2aeec9856000-2aeeca057000 rw-p 00000000 00:00 0
46. 2aeeca858000-2aeecb059000 rw-p 00000000 00:00 0
47. 2aeecb85a000-2aeecc85c000 rw-p 00000000 00:00 0
48. 2aeecd05d000-2aeecd85e000 rw-p 00000000 00:00 0
49. 2aeece05f000-2aeece361000 rw-p 00000000 00:00 0
50. 7ffc9fac3000-7ffc9fae4000 rw-p 00000000 00:00 0 [stack]
51. 7ffc9fb41000-7ffc9fb43000 r-xp 00000000 00:00 0 [vdso]
52. ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
53. (gdb) dump memory /paic/postgres/home/postgres/memory.dump 0x2aeeaf344000 0x2aeeafc8b000
54. $ strings -n 10 memory.dump
55. tt_pathmantest2_19127
56. tt_pathmantest2_19128
57. tt_pathmantest2_19129
58. tt_pathmantest2_19130
59. tt_pathmantest2_19131
60. tt_pathmantest2_19132 ……

61. (gdb) dump memory /paic/postgres/home/postgres/memory.dump 0x2aeeb074f000 0x2aeeb3827000
62. $ strings -n 10 memory.dump
63. pathman_tt_pathmantest2_3219_1_check
64. {BOOLEXPR :boolop and :args ({OPEXPR :opno 415 :opfuncid 472 :opresulttype 16 :opretset false :opcollid 0 :inputcollid 0 :args ({VAR :varno 1 :varattno 1 :vartype 20 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 1 :location -1} {CONST :consttype 20 :consttypmod -1 :constcollid 0 :constlen 8 :constbyval true :constisnull false :location -1 :constvalue 8 [ 8 -23 4 0 0 0 0 0 ]}) :location -1} {OPEXPR :opno 412 :opfuncid 469 :opresulttype 16 :opretset false :opcollid 0 :inputcollid 0 :args ({VAR :varno 1 :varattno 1 :vartype 20 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 1 :location -1} {CONST :consttype 20 :consttypmod -1 :constcollid 0 :constlen 8 :constbyval true :constisnull false :location -1 :constvalue 8 [ 108 -23 4 0 0 0 0 0 ]}) :location -1}) :location -1}o((id >= '321800'::bigint) AND (id < '321900'::bigint))
65. pathman_tt_pathmantest2_3220_1_check
66. {BOOLEXPR :boolop and :args ({OPEXPR :opno 415 :opfuncid 472 :opresulttype 16 :opretset false :opcollid 0 :inputcollid 0 :args ({VAR :varno 1 :varattno 1 :vartype 20 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 1 :location -1} {CONST :consttype 20 :consttypmod -1 :constcollid 0 :constlen 8 :constbyval true :constisnull false :location -1 :constvalue 8 [ 108 -23 4 0 0 0 0 0 ]}) :location -1} {OPEXPR :opno 412 :opfuncid 469 :opresulttype 16 :opretset false :opcollid 0 :inputcollid 0 :args ({VAR :varno 1 :varattno 1 :vartype 20 :vartypmod -1 :varcollid 0 :varlevelsup 0 :varnoold 1 :varoattno 1 :location -1} {CONST :consttype 20 :consttypmod -1 :constcollid 0 :constlen 8 :constbyval true :constisnull false :location -1 :constvalue 8 [ -48 -23 4 0 0 0 0 0 ]}) :location -1}) :location -1}o((id >= '321900'::bigint) AND (id < '322000'::bigint))
67. pathman_tt_pathmantest2_3221_1_check ……
</pre>

查看其他内存区域也是同样的结果。

删除pathman插件后（保留之前创建的分区表）,问题消失：

并对pathman源码做了分析发现，进程初始化时会加载所有pathman分区表配置信息到该进程私有内存空间，源码如下（其中黄色部分为pathman1.4以后新增内容）:

<pre>
17. /*
18. * Initialize per-process resources.
19. */
20. static void
21. init_local_cache(void)
22. {
23. HASHCTL ctl;
24. 
25. /* Destroy caches, just in case */
26. hash_destroy(partitioned_rels);
27. hash_destroy(parent_cache);
28. hash_destroy(bound_cache);
29. 

30. /* Reset pg_pathman's memory contexts */
31. if (TopPathmanContext)
32. {
33. /* Check that child contexts exist */
34. Assert(MemoryContextIsValid(PathmanInvalJobsContext));
35. Assert(MemoryContextIsValid(PathmanRelationCacheContext));
36. Assert(MemoryContextIsValid(PathmanParentCacheContext));
37. Assert(MemoryContextIsValid(PathmanBoundCacheContext));
38. 
39. /* Clear children */
40. MemoryContextResetChildren(TopPathmanContext);
41. }
42. /* Initialize pg_pathman's memory contexts */
43. else
44. {
45. Assert(PathmanInvalJobsContext == NULL);
46. Assert(PathmanRelationCacheContext == NULL);
47. Assert(PathmanParentCacheContext == NULL);
48. Assert(PathmanBoundCacheContext == NULL);
49. 
50. TopPathmanContext =
51. AllocSetContextCreate(TopMemoryContext,
52. CppAsString(TopPathmanContext),
53. ALLOCSET_DEFAULT_SIZES);
54. 
55. PathmanInvalJobsContext =
56. AllocSetContextCreate(TopMemoryContext,
57. CppAsString(PathmanInvalJobsContext),
58. ALLOCSET_SMALL_SIZES);
59. 
60. /* For PartRelationInfo */
61. PathmanRelationCacheContext =
62. AllocSetContextCreate(TopPathmanContext,
63. CppAsString(PathmanRelationCacheContext),
64. ALLOCSET_DEFAULT_SIZES);
65. 
66. /* For PartParentInfo */
67. PathmanParentCacheContext =
68. AllocSetContextCreate(TopPathmanContext,
69. CppAsString(PathmanParentCacheContext),
70. ALLOCSET_DEFAULT_SIZES);
71. 
72. /* For PartBoundInfo */
73. PathmanBoundCacheContext =
74. AllocSetContextCreate(TopPathmanContext,
75. CppAsString(PathmanBoundCacheContext),
76. ALLOCSET_DEFAULT_SIZES);
77. }

78. 
79. memset(&ctl, 0, sizeof(ctl));
80. ctl.keysize = sizeof(Oid);
81. ctl.entrysize = sizeof(PartRelationInfo);
82. ctl.hcxt = PathmanRelationCacheContext;
83. 
84. partitioned_rels = hash_create("pg_pathman's partition dispatch cache",
85. PART_RELS_SIZE, &ctl,
86. HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
87. 
88. memset(&ctl, 0, sizeof(ctl));
89. ctl.keysize = sizeof(Oid);
90. ctl.entrysize = sizeof(PartParentInfo);
91. ctl.hcxt = PathmanParentCacheContext;
92. 
93. parent_cache = hash_create("pg_pathman's partition parents cache",
94. PART_RELS_SIZE * CHILD_FACTOR, &ctl,
95. HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
96. 

97. memset(&ctl, 0, sizeof(ctl));
98. ctl.keysize = sizeof(Oid);
99. ctl.entrysize = sizeof(PartBoundInfo);
100. ctl.hcxt = PathmanBoundCacheContext;
101. 
102. bound_cache = hash_create("pg_pathman's partition bounds cache",
103. PART_RELS_SIZE * CHILD_FACTOR, &ctl,
104. HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
105. }
</pre>

而且pathman1.4之后的版本也只是解决了查询非pathman分区表的内存问题（PG11内置分区也一样），我们也在和pathman作者沟通，看能否将这部分内容放到共享内存，而不是进程的私有内存空间,解决高并发时导致OOM的问题。

## 解决方案

1. 读写分离：读写分离可以临时有效缓解内存不足的问题，而且实施难度和影响较小。
2. 历史分区合并：使用`merge_range_partitions`将2个月前历史分区由天分区合并为周分区。
3. 分表-历史表拆分：将历史表拆分为非分区表或者归档表，涉及业务改造量大。
4. 做好数据生命周期管理
5. 迁移MPP：纯分析型应用，可以迁移MPP数据库，彻底解决性能及资源问题。

![CENTER_PostgreSQL_Community](/images/news/2016/pg_bot_banner.jpg)