OOM杀手用大量的（？）免费RAM来杀死东西
尽pipe我的系统上有足够的可用内存，但是OOM杀手似乎正在杀死一些东西：
（完整分辨率）
（完整分辨率）
27分钟和408分钟后，系统再次开始响应。 大约一个小时后我重新启动了，不久之后，内存利用率恢复正常（对于本机）。
- 如何在电源中断后检查CentOS 6 Server VM Host？
- Linux – CentOS6 – semanage – 命令未find
- 使用apache作为HTTP代理的HTTPS
- 如何在Centos 6上获得openldap来将任何内容写入日志文件
- redis安装在centos 6.5上
经过检查，我的箱子上运行了一些有趣的程序：
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。 任何build议如何弄清楚为什么会发生这种情况将不胜感激！
编辑：附上vm。 sysctl tunables ..我一直在玩swappiness（通过它显而易见100），而且我也运行一个绝对可怕的脚本，它会转储我的缓冲区和caching（通过vm.drop_caches为3），每隔一段时间同步一次磁盘15分钟。 这就是为什么在重新启动之后，caching的数据增长到了一个正常的大小，但是之后又迅速下降了。 我认识到，caching是一件很好的事情，但直到我得出这个想法…
还有一点有趣的是，虽然我的页面文件在事件发展期间增长了，但是它只能达到总可能利用率的20％，这是真正的OOM事件的特征。 另一方面，磁盘在同一时间内绝对坚果，这是页面文件播放时的OOM事件的特征。
sysctl -a 2>/dev/null | grep '^vm' 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
我只是看着OOM日志转储，我质疑该图的准确性。 注意第一个“节点0 DMA32”线。 它说free:3376kB ， min:3448kB ， low:4308kB 。 每当自由值低于低值时，kswapd应该开始交换事物，直到该值回到高于最高值。 每当自由降到最低时，系统基本冻结，直到内核恢复到最小值以上。 该消息还表明，交换是完全使用的地方，它表示Free swap = 0kB 。
所以基本上kswapd被触发了，但swap已经满了，所以它什么都不能做，而pages_free的值仍然低于pages_min的值，所以唯一的select就是开始查杀东西，直到可以得到pages_free的备份。
你绝对没有记忆。
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html有一个非常好的解释，如何工作。 请参阅底部的“实施”部分。
摆脱drop_caches脚本。 另外，您应该发布显示OOM消息的dmesg和/var/log/messages输出的相关部分。
为了阻止这种行为，我build议使用这个sysctl可调参数。 这是一个RHEL / CentOS 6系统，显然运行在受限制的资源上。 它是一个虚拟机？
尝试修改/proc/sys/vm/nr_hugepages并查看问题是否存在。 这可能是一个内存碎片问题，但看看这个设置是否有所作为。 要使更改永久化，请将vm.nr_hugepages = value添加到/etc/sysctl.conf然后运行sysctl -p重新读取configuration文件…
另请参阅： 解读神秘的内核“页面分配失败”消息
从OOM杀手启动到结束时，图表上没有可用的数据。 我相信在graphics中断的时间范围内，实际上内存消耗确实激增，并且没有可用的内存了。 否则，OOM杀手不会被使用。 如果您在OOM杀手停止后观看空闲内存图表，则可以看到它从比以前更高的值下降。 至less它正确地完成了工作，释放了记忆。
请注意，您的交换空间几乎被充分利用，直到重新启动 这几乎从来都不是好事，有一个确定的迹象就是没有剩余的可用内存。
在特定时间段内没有数据可用的原因是因为系统太忙其他事情。 您的stream程清单中的“有趣”值可能只是一个结果，而不是一个原因。 这并不是闻所未闻的。
检查/var/log/kern.log和/ var / log / messages，你能find哪些信息？
如果日志logging也停止了，那就试试其他的东西，每隔一秒左右将进程列表转储到一个文件中，与系统性能信息一样。 以高优先级运行它，以便在负载峰值时能够继续工作（希望）。 虽然如果你没有一个抢先的内核（有时被称为“服务器”内核），你可能在这方面不太好运。
我想你会发现在你的问题开始的时候，使用最多CPU％的进程是原因。 我从来没有见过rsyslogd没有这样的行为。 更可能的罪魁祸首是Java应用程序和GUI驱动的应用程序，如浏览器。