尽管有可用内存，但OOM（缓存）

12

尽管我们将近一半的内存用于FS缓存，但我们一直在使用OOM杀手。我们每分钟记录一次内存统计信息（如上图所示），但是似乎有很多可用性。

...

Mem:  15339640k total, 15268304k used,    71336k free,     3152k buffers
Swap:        0k total,        0k used,        0k free,  6608384k cached

Mem:  15339640k total, 14855280k used,   484360k free,    13748k buffers
Swap:        0k total,        0k used,        0k free,  6481852k cached

[OOM killer: postgres killed]

Mem:  15339640k total,  8212200k used,  7127440k free,    32776k buffers
Swap:        0k total,        0k used,        0k free,  2394444k cached

...

来自系统日志的OOM详细信息：

...
Jun 10 05:45:25 db kernel: [11209156.840462] wal-e invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:25 db kernel: [11209156.840469] wal-e cpuset=/ mems_allowed=0
Jun 10 05:45:25 db kernel: [11209156.840474] Pid: 7963, comm: wal-e Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:25 db kernel: [11209156.840477] Call Trace:
Jun 10 05:45:25 db kernel: [11209156.840498]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:25 db kernel: [11209156.840502]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:25 db kernel: [11209156.840506]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
Jun 10 05:45:25 db kernel: [11209156.840511]  [<ffffffff8111f823>] __alloc_pages_nodemask+0x8c3/0x8e0
Jun 10 05:45:25 db kernel: [11209156.840520]  [<ffffffff81216e00>] ? noalloc_get_block_write+0x30/0x30
Jun 10 05:45:25 db kernel: [11209156.840528]  [<ffffffff811566c6>] alloc_pages_current+0xb6/0x120
Jun 10 05:45:25 db kernel: [11209156.840534]  [<ffffffff81116637>] __page_cache_alloc+0xb7/0xd0
Jun 10 05:45:25 db kernel: [11209156.840539]  [<ffffffff81118602>] filemap_fault+0x212/0x3c0
Jun 10 05:45:25 db kernel: [11209156.840553]  [<ffffffff81138c32>] __do_fault+0x72/0x550
Jun 10 05:45:25 db kernel: [11209156.840557]  [<ffffffff8113c2ea>] handle_pte_fault+0xfa/0x200
Jun 10 05:45:25 db kernel: [11209156.840562]  [<ffffffff8100638e>] ? xen_pmd_val+0xe/0x10
Jun 10 05:45:25 db kernel: [11209156.840567]  [<ffffffff81005309>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Jun 10 05:45:25 db kernel: [11209156.840571]  [<ffffffff8113d559>] handle_mm_fault+0x269/0x370
Jun 10 05:45:25 db kernel: [11209156.840576]  [<ffffffff8100a56d>] ? xen_force_evtchn_callback+0xd/0x10
Jun 10 05:45:25 db kernel: [11209156.840581]  [<ffffffff8100ad42>] ? check_events+0x12/0x20
Jun 10 05:45:25 db kernel: [11209156.840589]  [<ffffffff8165b3cb>] do_page_fault+0x14b/0x520
Jun 10 05:45:25 db kernel: [11209156.840594]  [<ffffffff81160d64>] ? kmem_cache_free+0x104/0x110
Jun 10 05:45:25 db kernel: [11209156.840600]  [<ffffffff811ba2c8>] ? ep_remove+0xa8/0xc0
Jun 10 05:45:25 db kernel: [11209156.840604]  [<ffffffff811bb133>] ? sys_epoll_ctl+0xb3/0x3d0
Jun 10 05:45:25 db kernel: [11209156.840614]  [<ffffffff81658035>] page_fault+0x25/0x30
Jun 10 05:45:25 db kernel: [11209156.840617] Mem-Info:
Jun 10 05:45:25 db kernel: [11209156.840618] Node 0 DMA per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840622] CPU    0: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840624] CPU    1: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840627] CPU    2: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840629] CPU    3: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840631] Node 0 DMA32 per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840634] CPU    0: hi:  186, btch:  31 usd:  30
Jun 10 05:45:25 db kernel: [11209156.840637] CPU    1: hi:  186, btch:  31 usd:  47
Jun 10 05:45:25 db kernel: [11209156.840639] CPU    2: hi:  186, btch:  31 usd:  15
Jun 10 05:45:25 db kernel: [11209156.840641] CPU    3: hi:  186, btch:  31 usd:   2
Jun 10 05:45:25 db kernel: [11209156.840643] Node 0 Normal per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840646] CPU    0: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840648] CPU    1: hi:  186, btch:  31 usd:  14
Jun 10 05:45:25 db kernel: [11209156.840650] CPU    2: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840653] CPU    3: hi:  186, btch:  31 usd:   1
Jun 10 05:45:25 db kernel: [11209156.840658] active_anon:3616567 inactive_anon:4798 isolated_anon:0
Jun 10 05:45:25 db kernel: [11209156.840660]  active_file:98 inactive_file:168 isolated_file:20
Jun 10 05:45:25 db kernel: [11209156.840661]  unevictable:1597 dirty:73 writeback:0 unstable:0
Jun 10 05:45:25 db kernel: [11209156.840662]  free:16921 slab_reclaimable:17631 slab_unreclaimable:7534
Jun 10 05:45:25 db kernel: [11209156.840663]  mapped:1614529 shmem:1613928 pagetables:124012 bounce:0
Jun 10 05:45:25 db kernel: [11209156.840666] Node 0 DMA free:7888kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:7632kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840681] lowmem_reserve[]: 0 4016 15112 15112
Jun 10 05:45:25 db kernel: [11209156.840686] Node 0 DMA32 free:48368kB min:4176kB low:5220kB high:6264kB active_anon:3776804kB inactive_anon:28kB active_file:0kB inactive_file:20kB unevictable:932kB isolated(anon):0kB isolated(file):0kB present:4112640kB mlocked:932kB dirty:0kB writeback:0kB mapped:1458536kB shmem:1458632kB slab_reclaimable:17604kB slab_unreclaimable:8088kB kernel_stack:1872kB pagetables:190616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:437 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840698] lowmem_reserve[]: 0 0 11095 11095
Jun 10 05:45:25 db kernel: [11209156.840703] Node 0 Normal free:11428kB min:11548kB low:14432kB high:17320kB active_anon:10689464kB inactive_anon:19164kB active_file:528kB inactive_file:652kB unevictable:5456kB isolated(anon):0kB isolated(file):80kB present:11362176kB mlocked:5456kB dirty:292kB writeback:0kB mapped:4999580kB shmem:4997080kB slab_reclaimable:52920kB slab_unreclaimable:22048kB kernel_stack:2584kB pagetables:305432kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1974 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840715] lowmem_reserve[]: 0 0 0 0
Jun 10 05:45:25 db kernel: [11209156.840720] Node 0 DMA: 2*4kB 3*8kB 1*16kB 3*32kB 3*64kB 3*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 0*4096kB = 7888kB
Jun 10 05:45:25 db kernel: [11209156.840752] Node 0 DMA32: 5813*4kB 2636*8kB 114*16kB 15*32kB 5*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 48372kB
Jun 10 05:45:25 db kernel: [11209156.840776] Node 0 Normal: 1888*4kB 10*8kB 46*16kB 4*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 11760kB
Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages
Jun 10 05:45:25 db kernel: [11209156.840790] 0 pages in swap cache
Jun 10 05:45:25 db kernel: [11209156.840801] Swap cache stats: add 0, delete 0, find 0/0
Jun 10 05:45:25 db kernel: [11209156.840803] Free swap  = 0kB
Jun 10 05:45:25 db kernel: [11209156.840805] Total swap = 0kB
Jun 10 05:45:25 db kernel: [11209156.909794] 3934192 pages RAM
Jun 10 05:45:25 db kernel: [11209156.909804] 99282 pages reserved
Jun 10 05:45:25 db kernel: [11209156.909809] 18899146 pages shared
Jun 10 05:45:25 db kernel: [11209156.909811] 2198511 pages non-shared
Jun 10 05:45:25 db kernel: [11209156.909817] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
Jun 10 05:45:25 db kernel: [11209156.909835] [  332]     0   332     4308      109   1       0             0 upstart-udev-br
Jun 10 05:45:25 db kernel: [11209156.909845] [  346]     0   346     5384      271   2     -17         -1000 udevd
Jun 10 05:45:25 db kernel: [11209156.909851] [  408]     0   408     5364      174   2     -17         -1000 udevd
...
Jun 10 05:45:25 db kernel: [11209156.910703] [ 7963]   111  7963    17456     2966   0       0             0 wal-e
Jun 10 05:45:25 db kernel: [11209156.910707] [ 7968]   111  7968  1639372     2351   3       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910711] [ 7969]   111  7969  1639371     1934   2       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910716] Out of memory: Kill process 12443 (postgres) score 418 or sacrifice child
Jun 10 05:45:25 db kernel: [11209156.910733] Killed process 12443 (postgres) total-vm:6555152kB, anon-rss:4600kB, file-rss:6396572kB
Jun 10 05:45:30 db kernel: [11209159.293083] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:31 db kernel: [11209159.293091] postgres cpuset=/ mems_allowed=0
Jun 10 05:45:31 db kernel: [11209159.293095] Pid: 6508, comm: postgres Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:31 db kernel: [11209159.293098] Call Trace:
Jun 10 05:45:31 db kernel: [11209159.293111]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:31 db kernel: [11209159.293115]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:31 db kernel: [11209159.293119]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
...

我们可以尝试将这些分辨率提高到大约每秒一次，但是这里是否有任何OOM的理由？（我们已经看过http://bl0rg.krunch.be/oom-frag.html，但是我们正在使用更大的绝对内存，其中大部分是由内核的FS缓存占用的。）

还包括postgresql.conf以下我们的相关部分：

shared_buffers = 6GB
effective_cache_size = 8GB
postgresql  oom 
— 杨
source
2
— Yang
嗯... 3.2.0-43？更新时间。随着时间的流逝，OOM杀手经历了许多（太多）变化。某些版本在考虑共享内存使用方面确实非常不明智...例如PostgreSQL 9.2和更早版本shared_buffers。
— Craig Ringer 2013年
@CraigRinger不幸的是，还有其他考虑因素，包括坚持Ubuntu 12.04发行版中的内核以获取LTS，兼容性，安全更新等。如果有人知道如何解释此处发生的事情，我们只是感兴趣-如果有帮助，假装我们正在对改变现状不感兴趣/使问题消失。BTW shared_buffers仍在PG9.3中。
— 杨
是shared_buffers的仍然在9.3中，但是它不再是9.3中的POSIX共享内存。它已被匿名mmap()ed区域替换。尽管我怀疑这会使OOM杀手less少些困惑，但可以解决一些棘手的内核配置问题和固定问题。
— Craig Ringer 2013年
1
可能是serverfault.com/questions/288319/…的副本，可能有答案。
— richvdh

Answers:

4

看来您（和我的症状非常相似）确实已经用尽了内存，并对cached数字感到困惑。

显然，在某些情况下，当内存需求上升时，Linux无法释放大量磁盘缓存

特别是（我不太明白为什么），postgres shared_buffers可能会在“缓存”（页面缓存）下报告。在您的情况下，6481852k cachedin top与OOM-killer日志中的以下行匹配：

Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages

（1615243 * 4KB〜= 6481852k）-表示在调用OOM-killer之前确实没有删除页面缓存。

但是，文件支持的页面很少（我假设active_file:98 inactive_file:168与/ proc / meminfo的Active（file）/ Inactive（file）相似），因此它不是我们了解和喜爱的可丢弃页面。

https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/上的帖子演示了一个示例会话，其中关闭postgres会导致减少“缓存”的大小shared_buffers（滚动到“并且大多数都脱离了磁盘缓存–就像预期的那样，因为它用于shared_buffers。”）–不幸的是，它没有指出postgres的版本，也没有指出用于实验的内核。

我在PG 9.3上使用3.13.0-67 x86_64。在9.3中，他们从使用Sys V共享内存（shmget）切换为匿名mmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork()（在9.4中，可以通过dynamic_shared_memory_type进行配置）。但是我找不到关于为什么这些mmap（）应该显示在“已缓存”中以及为什么的解释，为什么只有https://access.redhat.com/solutions/406773会显示“已缓存： pagecache（磁盘缓存和共享内存）”

鉴于共享内存的种类很多，我既被启发又感到困惑...

— 尼古拉
source
几年后，这是一个更好的答案，谢谢。仍然存在一个问题，为什么将其视为已缓存，但是我现在将其标记为接受。
— 杨
8

  1. 为了热爱世界上一切美好的事物，请在服务器上配置交换空间。
    您确实需要交换空间。我不是唯一这样说的人，这几乎是这里的普遍真理。（<-这是三个链接）
    当然，您应该有足够的RAM以确保数据库服务器不定期交换 -如果您不解决的话，那就是钱（您可以带走您的供应商并用来获取更多的RAM） 。

  2. 由于您现在有足够的RAM，并且在出现问题时可以交换使用，因此可以禁用OOM杀手（通过禁用内存过量使用），就像Postgres员工告诉您的那样。
    （您还可以应用他们的替代解决方案，并告诉OOM-Killer永远不要杀死Postgres-但是您只是在与系统的其余过程一起玩Russian Roulette ...）

  3. （可选）在服务器故障上写一个答案，详细说明为什么大多数Linux发行版中的默认行为是Bad，Wrong，并且违反了POSIX规范中malloc（）的行为方式。重复此过程，直到每个人都厌倦了关于它的消息。

还要注意，内核的缓存内存可供postgres（或任何其他应用程序）使用-您应在计算中将其视为可用/可用内存。

如果我不得不猜测一下这里发生的事情，我会说您有一个复杂的查询，Postgres要求RAM执行它，而不是说“我没有那个RAM”，Linux告诉Postgres“当然，你可以拥有它。”
然后，当Postgres的实际上是尝试使用的RAM是（据说）给出的Linux实现不HAVE它所承诺的Postgres的RAM（因为它是过量使用） -的OOM杀手被告知要释放的内存，并使用尽职尽责地杀死程序内存最多-您的数据库服务器。

Postgres是一个精心设计的程序。如果告知它没有RAM，则它会请求它优雅地处理（通过少做一些或中止向用户发送消息）。

— voretaq7
source
4
感谢您对交换的详细说明，但这并不能回答我为什么会首先发生这种问题。是的，我了解默认情况下Linux会过量使用的基本前提，而OOM是当我们内存不足时-我本可以在最初的问题中这么说。但是问题是为什么当我仍然有足够的RAM时（为什么大部分内存都位于FS缓存中）为什么会启动？假设我什至对改变任何东西都不感兴趣-只要我了解为什么会触发OOM杀手就可以了。
— 杨
2
在检查了链接之后，不幸的是，有一些断言没有支持证据或具体的技术解释。当然，在很多Linux环境中，甚至都没有交换选项（例如：在Live CD上再没有现有的本地交换分区可以重用）。此外，我们对根据自己的经验和环境实现交换性不感兴趣-我们宁愿拥有OOM。原始问题的答案将不胜感激。
— 杨
1
@Yang我认为，如果您要为Postgres构建服务器，则需要遵循Postgres项目的建议。我的回答是按照他们告诉您的方式做（关闭OOM杀手）。如果您想等待，看看是否有人为您提供不同的答案，那么您当然可以这样做，但是我不愿意提供任何其他解决方案-我认为OOM杀手是坏，错误的，并且违反了POSIX。它在台式机/工作站上是可以接受的，但在IMO上，将其禁用是服务器上的“正确的事情”。
— voretaq7 2013年
2
我曾在确实具有交换功能的服务器上遇到过这种情况，并且在可用内存+交换饱和之后，使用了OOM杀手，而不是内核回收了“缓存”内存，而后者显然已被锁定。我从来没有解决过这个问题，但是@Yang的原始问题在这里没有得到回答。
— Patrick
2
交换不是答案，它只会使问题稍后出现。RAM满时需要交换，而RAM + swap满时需要OOM Killer。如果交换数量为零，则需要尽快使用OOM Killer，但无法避免使用交换的OOM Killer。
— Mikko Rantalainen '18 -10-10
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.