尽管我的系统上有足够的可用 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 小时，只有这两个进程具有如此奇怪的值。我怀疑“其他事情”正在发生，可能与这些无意义的值有关。具体来说，我认为系统想认为内存不足，但实际上并非如此。毕竟，它认为 rsyslogd 持续使用 55383984% 的 CPU，而该系统的理论最大值无论如何都是 400%。
这是最新的 CentOS 6 安装 (6.2)，具有 768MB 的 RAM。如果您能提供任何有关如何找出这种情况发生原因的建议，我们将不胜感激！
编辑：附加 vm. 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
答案1
我刚刚查看了 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对其工作原理有很好的解释。请参阅底部的“实施”部分。
答案2
删除 drop_caches 脚本。此外，您还应发布显示 OOM 消息的输出dmesg的相关部分。/var/log/messages
不过，为了阻止这种行为，我建议尝试这个sysctl可调参数。这是一个 RHEL/CentOS 6 系统，显然在受限的资源上运行。它是虚拟机吗？
尝试修改/proc/sys/vm/nr_hugepages并查看问题是否仍然存在。这可能是内存碎片问题，但请查看此设置是否有所不同。要使更改永久生效，请添加vm.nr_hugepages = value到您的/etc/sysctl.conf并运行sysctl -p以重新读取配置文件...
另请参阅：解释神秘的内核“页面分配失败”消息
答案3
从 OOM 杀手启动到结束，图表上没有可用数据。我相信在图表中断的时间范围内，内存消耗确实会激增，并且不再有可用内存。否则 OOM 杀手不会被使用。如果您在 OOM 杀手停止后查看可用内存图表，您会发现它从比之前更高的值下降。至少它正确地完成了它的工作，释放了内存。
请注意，在重新启动之前，您的交换空间几乎已完全使用。这几乎不是什么好事，并且肯定表明剩余的可用内存很少。
特定时间范围内没有可用数据的原因是系统忙于处理其他事务。进程列表中的“奇怪”值可能只是结果，而不是原因。这种情况并不罕见。
检查 /var/log/kern.log 和 /var/log/messages，您可以在那里找到什么信息？
如果日志记录也停止了，那么请尝试其他方法，每隔一秒左右将进程列表转储到文件中，系统性能信息也是如此。以高优先级运行它，这样当负载激增时它仍然可以完成其工作（希望如此）。尽管如果您没有抢占内核（有时表示为“服务器”内核），您在这方面可能会运气不佳。
我认为您会发现问题开始时占用最多 CPU% 的进程就是原因。我从未见过 rsyslogd 或 mysql 有这样的行为。更可能的罪魁祸首是 Java 应用程序和 GUI 驱动的应用程序，例如浏览器。