OOMキラーはたくさんの無料の物を殺す（？）RAM
OOMキラーは、システムに十分な空き容量があるにもかかわらず、物事を殺しているようですRAM私のシステム：
27分と408プロセス後、システムは再び応答を開始しました。約1時間後に再起動しましたが、その後すぐにメモリ使用率は通常に戻りました（このマシンの場合）。
検査すると、ボックスでいくつかの興味深いプロセスが実行されています。
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時間、そしてこれらはそのような...奇数の値を持つ唯一の2つのプロセスです。私の疑いは、「何か他のもの」が起こっているということであり、これらの非意味的な値に潜在的に関連しています。具体的には、システムはメモリ不足だと考えていますと思いますが、実際にはそうではありません。結局のところ、とにかくこのシステムの理論上の最大値が400％である場合、rsyslogdは55383984％のCPUを一貫して使用していると考えています。
これは、768MBのRAMを備えた完全に最新のCentOS 6インストール（6.2）です。なぜこれが起こっているのかを理解する方法についての提案はいただければ幸いです！
編集：vmをアタッチします。 sysctlチューナブル..私はswappiness（それが100であることで明らかとなった）で遊んでおり、私をダンプする絶対terribleスクリプトも実行していますバッファとキャッシュ（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
私はoomのログダンプを見ただけで、そのグラフの正確さに疑問があります。最初の「Node 0 DMA32」行に注意してください。 free:3376kB、min:3448kB、low:4308kB。 free値がlow値を下回ると、kswapdは、その値がhigh値を超えるまでスワップを開始することになっています。 freeがminを下回ると、カーネルがmin値を超えるまでシステムは基本的にフリーズします。そのメッセージは、スワップが完全に使用されたことを示しています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 は、それがどのように機能するかについて本当に良い説明をしています。下部の「実装」セクションを参照してください。
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を実行して構成ファイルを再度読み取ります...
以下も参照してください。 不可解なカーネルの「ページ割り当て失敗」メッセージの解釈
OOMキラーが開始してから終了するまで、グラフに利用可能なデータはありません。グラフが中断される時間枠では、実際にはメモリ消費が急増し、使用可能なメモリがなくなったと思います。それ以外の場合、OOMキラーは使用されません。 OOMキラーが停止した後に空きメモリグラフを見ると、以前よりも高い値から低下していることがわかります。少なくともそれは適切に機能し、メモリを解放しました。
再起動するまで、スワップ領域はほぼ完全に使用されていることに注意してください。これはほとんど決して良いことではなく、空きメモリがほとんど残っていないことを示しています。
その特定の時間枠で利用可能なデータがない理由は、システムが他のもので忙しすぎるためです。プロセスリストの「おかしい」値は、結果ではなく、原因である可能性があります。それは前代未聞ではありません。
/var/log/kern.logおよび/ var/log/messagesを確認してください。そこにはどのような情報がありますか？
ロギングも停止した場合は、他のことを試し、システムパフォーマンス情報と同じように、プロセスリストを毎秒程度ファイルにダンプします。高い優先度で実行して、負荷が急上昇した場合でも（うまくいけば）仕事ができるようにします。プリエンプトカーネル（「サーバー」カーネルとして示されることもある）がない場合は、その点で運が悪い場合があります。
問題が発生した頃にCPU使用率が最も高いプロセスが原因であることがわかります。私はrsyslogdもmysqlもそのように動作するのを見たことがありません。より可能性の高い犯人は、JavaアプリおよびブラウザーなどのGUI駆動アプリです。