OOM杀手使用大量（？）可用RAM杀死事物

尽管我的系统上有足够的可用RAM，但OOM杀手似乎正在杀死东西：

27分钟和408个处理之后，系统再次开始响应。大约一个小时后，我重新启动了它，此后不久，内存使用率恢复了正常（对于这台机器）。

经过检查，我的计算机上运行了一些有趣的过程：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

这个特定的服务器已经运行了大约。8小时，这是仅有的两个具有此类...奇数值的过程。我怀疑“其他”正在发生，可能与这些无意义的价值观有关。具体来说，我认为系统认为内存不足，而实际上并非如此。毕竟，当该系统上的理论最大值为400％时，它认为rsyslogd始终使用55383984％CPU。

这是具有768MB RAM的最新的CentOS 6安装（6.2）。关于如何弄清楚为什么会发生任何建议，将不胜感激！

编辑：附加虚拟机。sysctl可调参数..我一直在使用swappiness（通过100可以明显看出），并且我还在运行一个绝对糟糕的脚本，该脚本会转储我的缓冲区和缓存（通过vm.drop_caches可以通过3实现）+每次都同步磁盘15分钟。这就是为什么在重新启动后，缓存的数据增长到某种程度的正常大小，然后又迅速下降的原因。我认识到拥有缓存是一件非常好的事情，但是直到我弄清楚了...

还有一点有趣的是，尽管我的页面文件在活动期间增长了，但它只能达到总可能利用率的20％，这与真正的OOM事件不同。另一方面，磁盘在同一时间段内完全失去作用，这是页面文件正在播放时的OOM事件的特征。

sysctl -a 2>/dev/null | grep '^vm'：

vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.extfrag_threshold = 500
vm.oom_dump_tasks = 0
vm.would_have_oomkilled = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 100
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.drop_caches = 3
vm.min_free_kbytes = 3518
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.numa_zonelist_order = default
vm.scan_unevictable_pages = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1

编辑：并附加第一个OOM消息...经过更仔细的检查，这就是说显然也有东西吃掉了我的整个交换空间。

Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0
Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1
Feb 21 17:12:51 host kernel: Call Trace:
Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0
Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110
Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0
Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210
Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850
Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100
Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90
Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210
Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510
Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500
Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0
Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10
Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Feb 21 17:12:51 host kernel: Mem-Info:
Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:  186, btch:  31 usd:  47
Feb 21 17:12:51 host kernel: CPU    1: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:  186, btch:  31 usd: 174
Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0
Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0
Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0
Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139
Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0
Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741
Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0
Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB
Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB
Feb 21 17:12:51 host kernel: 4685 total pagecache pages
Feb 21 17:12:51 host kernel: 4131 pages in swap cache
Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901
Feb 21 17:12:51 host kernel: Free swap  = 0kB
Feb 21 17:12:51 host kernel: Total swap = 523256kB
Feb 21 17:12:51 host kernel: 196607 pages RAM
Feb 21 17:12:51 host kernel: 6737 pages reserved
Feb 21 17:12:51 host kernel: 33612 pages shared
Feb 21 17:12:51 host kernel: 180803 pages non-shared
Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child
Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB

— 凯尔·布兰特利（Kyle Brantley）
source

你能提供输出sysctl -a 2>/dev/null | grep '^vm'吗？

— Patrick

添加。希望您（或某人）能找到我想念的东西。

— 凯尔·布兰特利

唯一让我跳出来的就是overcommit_memory背景。将其设置为1 不应导致此行为，但是我以前从未需要将其设置为“始终过量使用”，因此那里没有太多经验。查看添加的其他注释，您说交换仅使用了20％。但是，根据OOM日志转储，Free swap = 0kB。绝对认为交换已被100％使用。

— Patrick

Answers:

我只是查看了oom日志转储，并对该图形的准确性提出了疑问。注意第一行“ Node 0 DMA32”行。它说free:3376kB，min:3448kB和low:4308kB。每当自由值降到低值以下时，kswapd应该开始交换东西，直到该值恢复到高值以上为止。只要空闲时间降到最小值以下，系统基本上就会冻结，直到内核将其恢复到最小值以上。该消息还表明交换已完全使用Free swap = 0kB。
因此，基本上是kswapd触发了，但是交换已满，因此它无能为力，并且pages_free值仍低于pages_min值，因此唯一的选择是开始杀死事物，直到它可以使pages_free备份为止。
您肯定用光了内存。

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html对它的工作原理有很好的解释。请参阅底部的“实施”部分。

— 帕特里克
source

因此，OP确实确实只需要更多RAM ...

— ewwhite

更多公羊，或找出吃什么。

— Patrick

我非常精确地将线放在该图上。在第一个进程被杀死之前，它停止记录数据约1-2m，而在最后一个进程被杀死之后，它恢复了记录数据约4-5m。在这一点上，我敢打赌某个进程绝对会陷入困境，并开始破坏我的页面文件-一旦它最终获得了一切，它也杀死了在功能上用尽页面文件的进程，这就是为什么当数据返回时，页面文件已提升但未满。欢迎提供有关如何确定执行此操作的建议！

— 凯尔·布兰特利

@KyleBrantley您要提取什么值才能生成图形？linux虚拟内存系统的缺点之一是没有关于“免费”的具体定义。定义“空闲内存”的方法有十二种。就kswapd而言，最重要的是pages_free值。至于免费掉期，我不知道您可能会读到什么价值，那么远。真正看到消耗内存的唯一方法是在包装盒上记录所有进程的连续快照，并在oom killer开始崩溃时查看消耗所有内存的内容。

— Patrick

是的，我内存不足。我仔细检查了日志，发现我的apache子进程被反复杀死，这使我弄清楚了我可以启动的功能无限的子进程。它所需要的只是自动化的Blogspam僵尸程序每秒向主机抛出大量请求以使其崩溃。调整apache解决了所有问题。

— 凯尔·布兰特利

摆脱drop_caches脚本。另外，您应该张贴您的相关部分，dmesg并/var/log/messages输出显示OOM消息。

但是，要停止这种行为，我建议尝试使用此sysctl可调参数。这是一个RHEL / CentOS 6系统，显然在受限资源上运行。它是虚拟机吗？

尝试修改/proc/sys/vm/nr_hugepages，看看问题是否仍然存在。这可能是内存碎片问题，但请查看此设置是否有所不同。要使更改永久生效，请添加vm.nr_hugepages = value到/etc/sysctl.conf并运行sysctl -p以重新读取配置文件...

另请参阅：解释神秘内核“页面分配失败”消息

— 怀特
source

添加了第一个oom-killer消息。虽然MySQL是我正在运行的最消耗RAM的东西，但我对其进行了调整，以免使其不堪重负，因此，除了我在顶部看到的疯狂价值观之外，我并没有真正怀疑它（5.1％内存使用情况很好，考虑所有因素）。这是一个VPS，具有768MB的RAM。我会仔细阅读nr_hugepages并试一试，谢谢！

— 凯尔·布兰特利

@ewwhite分配了很多大页面会杀死盒子。该盒子只有768mb的ram，默认的hugepagesz为2mb，这将分配2gb的hugepages。盒子将无法处理，并立即死亡。

— Patrick

更新。但是，该值应从零开始增加。

— ewwhite 2012年

比这还复杂的多。您必须设置大页面权限，并且必须将mysql配置为使用大页面，否则您将无缘无故地分配它们。

— Patrick

从OOM杀手启动到结束，图表上没有可用数据。我相信在图表被中断的时间范围内，实际上内存消耗确实会激增，并且不再有可用内存。否则，将不会使用OOM杀手。如果在OOM杀手停止运行后观看空闲内存图，您会发现它的值从以前的更高开始下降。至少它能正常工作，释放内存。

请注意，在重新启动之前，交换空间几乎已被充分利用。那几乎从来都不是一件好事，而且可以肯定的迹象是几乎没有剩余的可用内存。

在该特定时间范围内没有可用数据的原因是系统忙于其他事情。流程列表中的“有趣”值可能只是结果，而不是原因。这不是闻所未闻的。

检查/var/log/kern.log和/ var / log / messages，在那里可以找到什么信息？

如果日志记录也停止了，请尝试其他操作，每秒钟左右将进程列表转储到文件中，并记录系统性能信息。以高优先级运行它，以便在负载达到峰值时仍可以（希望）完成其工作。尽管如果您没有抢占式内核（有时表示为“服务器”内核），则在这方面可能会不走运。

我认为您会发现问题开始时大约占用最多CPU％的进程是原因。我从未见过rsyslogd和mysql都没有这种行为。可能的罪魁祸首是Java应用程序和GUI驱动的应用程序，例如浏览器。

— 平等
source

没有数据存在，因为盒子上的负载突如其来地飙升到很高，以至于包括监视代理程序在内的所有东西都被磨碎了。该代理程序本身在濒死期间从未真正被杀死，但也无法报告任何数据。我的交换空间实际上很好。在重新启动之前，它总共使用了约130 / 512MB。rsyslogd配置为将日志报告到网络位置，该日志记录了所发生的所有事件-并杀死了408个进程（其中一些是重新启动的apache子进程），没有任何异常。

— 凯尔·布兰特利

如果我实际上无法弄清楚这里发生了什么，我可能每隔几秒钟就将完整的进程列表转储到文件（或网络）中，因此，谢谢您的好主意。

— 凯尔·布兰特利

是的，您应该这样做，并确保还记录每个进程的CPU使用率，并查看“ top -b”（批处理模式）。突增的过程可能是罪魁祸首。

— aseq 2012年