私はARMベースの組み込みプラットフォームを開発しています。 32ビット、512MB RAM、スワップ領域なし。 Linux 3.10.53（該当する場合はUbuntuの一部のバリエーション）
私が作業しているいくつかのコードは、oomによって引き続き終了します。実際に測定した内容によれば、コードの終了時に使用可能なメモリが十分にあることがわかります。原因は何ですか？
プロセスを実行する前のfree -mレポート約320MB無料また、/proc/meminfoのLowFree数に近い。 ps -e -o vsizeのすべての数値の合計は約212MBで、/proc/meminfoのフラットデータは約10MBです。これは、222MBを超えないことを間接的に示しています。のスペースを使用する必要があり、これはFree Memoryの下のデータとほぼ一致します。
その後、コードを実行し、しばらくするとoomによって終了します。 dmesgのコメントには、プロセスに次のものがあることが示されています。合計サイズ180 MB;これは300MBよりはるかに少ないので実行する前には無料と言います。 oom-killerをトリガーするのは、このプロセス自体のメモリ要求です。
（確かにプロセスを殺すUmkillerです。dmesgにあまりにも多くの内容があり、私のulimitは無制限です。）
シンプルなプログラム
私は私が理解していない主な問題を再現するために非常に単純なプログラムを使用できることを発見しました。私はこれを説明してから（誰かが興味があれば）もともと私に送られ、より広範囲にテストされたより複雑なプログラムに戻ります。
ここにいくつかのコードがあります。退屈な#includeは省略されます。通常C。
int main(void) {
int i=0, j;
char * p;
while (1) {
fprintf(stderr, "allocating block %d\n", ++i);
p = malloc(10000000);
for (j=0; j<10000000; ++j) p[j] = j; /* touch memory */
}
return 0;
}
「プログラム」を実行する前に、約320MB程度の空き容量があるようです。 16個の10MBブロックを割り当ててから17番目のブロックを割り当てようとすると強制終了します。
さて、今は元のプログラムに戻ります。
このショーはもともと
strace -e Trace = memoryを使用してプロセスを実行すると（brkおよびm [un] map2への呼び出しが表示されます）、最初に出力が180 MBのプロセスサイズと一致するようです。 2番目は、プロセスが以前に実行されたときです。全滅した。クォータは約15MBです。
gdbでプロセスを実行して終了するまで、できるだけ長く停止すると次のようになります。
- /proc/meminfoのLowFree番号はまだ約230MBです。
- /proc/meminfoの他の数字のどれも、追加のメモリが使用されていることを示していないようです。 （例えば、slabはまだ約10 MBなので、プロセスが何らかの方法でカーネルが大量のメモリを割り当てるようにはしません。）
- psは、プロセスのvsizeが約165MBであると報告します（これは、15MBの割り当てが180MBになるのと一致し、これは明らかにoom-killerがプロセスを終了したときに発生する現象です）。
- gdbは
info proc mappings私に疑わしいように見えるものを表示しません。 [追加するように編集しました：]とは別にそれ- リストされている領域の1つには同じ名前があり
[stack:14958]、数字は私のスレッドの1つのLWP IDmallocですnew。そのような領域がありますが、heapはるかに小さいです。 - プロセスを追跡すると、これらすべての大きなメモリ割り当てが実際に背後にマッピングされていることがわかります。この説明だけで十分だと思います（したがって、誤解を招く「スタック」の名前）。だからわからない。 （これらのmmap呼び出しによって返されたメモリブロックがこの領域内にあることを確認しました。）
- リストされている領域の1つには同じ名前があり
（おそらく関連している可能性があります：gdbが停止すると奇妙に動作し始めます。たとえば、continue「警告：汎用レジスタを取得できません」というメッセージが表示され、プログラムを実行できないようです。）これはおそらく一部のリソースですによって引き起こされた枯渇のようです。 )
[追加編集：gdbで実行すると、プロセスは早期に終了します。これはgdb自体が無視できない量のメモリを使用するため、驚くべきことではありません。 gdbで正確にいつ死ぬかは、私が設定したブレークポイントによって異なります。 ]
これは vm.overcommit_memory=0 および vm.overcommit_ratio=50 を使用して達成されます。オーバーコミット率を90に増やしても何も変わらないようです（しかし、meminfoのCommitLimit数が適切に増加することを確認しました）。
vm.overcommit_memory = 2（オーバーコミットをオフにする必要があることを理解しています）を設定しても何も変わらないようです。これは少し混乱します（オーバーコミットを無効にすると、割り当てが成功するのではなく、進行中に失敗してはいけません）。ウムキラーを引き起こすか？）。
oom-killerログで最も関連性の高い情報は次のとおりです。
Sep 24 11:02:04 wandboard kernel: MY_PROCESS_NAME invoked oom-killer: gfp_mask=0x2084d0, order=0, oom_score_adj=0
Sep 24 11:02:04 wandboard kernel: CPU: 0 PID: 14294 Comm: MY_PROCESS_NAME Not tainted 3.10.53-1.1.0_ga-wandboard-06034-g13bb184-dirty #1
Sep 24 11:02:04 wandboard kernel: [<80013acc>] (unwind_backtrace+0x0/0xf8) from [<80011544>] (show_stack+0x10/0x14)
Sep 24 11:02:04 wandboard kernel: [<80011544>] (show_stack+0x10/0x14) from [<8067d0cc>] (dump_header.isra.10+0x64/0x188)
Sep 24 11:02:04 wandboard kernel: [<8067d0cc>] (dump_header.isra.10+0x64/0x188) from [<80092170>] (oom_kill_process+0x270/0x3c8)
Sep 24 11:02:04 wandboard kernel: [<80092170>] (oom_kill_process+0x270/0x3c8) from [<80092710>] (out_of_memory+0x27c/0x2d4)
Sep 24 11:02:04 wandboard kernel: [<80092710>] (out_of_memory+0x27c/0x2d4) from [<80096568>] (__alloc_pages_nodemask+0x834/0x85c)
Sep 24 11:02:04 wandboard kernel: [<80096568>] (__alloc_pages_nodemask+0x834/0x85c) from [<800ab4a0>] (__pte_alloc+0x24/0x13c)
Sep 24 11:02:04 wandboard kernel: [<800ab4a0>] (__pte_alloc+0x24/0x13c) from [<800ae474>] (handle_mm_fault+0xdc/0xf0)
Sep 24 11:02:04 wandboard kernel: [<800ae474>] (handle_mm_fault+0xdc/0xf0) from [<800185e4>] (do_page_fault+0x208/0x368)
Sep 24 11:02:04 wandboard kernel: [<800185e4>] (do_page_fault+0x208/0x368) from [<80008370>] (do_DataAbort+0x34/0x9c)
Sep 24 11:02:04 wandboard kernel: [<80008370>] (do_DataAbort+0x34/0x9c) from [<8000deb4>] (__dabt_usr+0x34/0x40)
Sep 24 11:02:04 wandboard kernel: Exception stack(0x8b6a1fb0 to 0x8b6a1ff8)
Sep 24 11:02:04 wandboard kernel: 1fa0: 6dd95001 7ed706a8 6cdfffff 000000e6
Sep 24 11:02:04 wandboard kernel: 1fc0: 6dd95001 000006f2 00000603 7ed706c8 0014c0a0 7ed70910 00000003 7ed706f4
Sep 24 11:02:04 wandboard kernel: 1fe0: 6cdffffe 7ed70690 6ce00000 00195a6c 200f0010 ffffffff
Sep 24 11:02:04 wandboard kernel: Mem-info:
Sep 24 11:02:04 wandboard kernel: DMA per-cpu:
Sep 24 11:02:04 wandboard kernel: CPU 0: hi: 42, btch: 7 usd: 33
Sep 24 11:02:04 wandboard kernel: active_anon:44721 inactive_anon:36 isolated_anon:0
Sep 24 11:02:04 wandboard kernel: active_file:7 inactive_file:1 isolated_file:0
Sep 24 11:02:04 wandboard kernel: unevictable:0 dirty:0 writeback:0 unstable:0
Sep 24 11:02:04 wandboard kernel: free:40238 slab_reclaimable:720 slab_unreclaimable:1594
Sep 24 11:02:04 wandboard kernel: mapped:4 shmem:77 pagetables:257 bounce:0
Sep 24 11:02:04 wandboard kernel: free_cma:39999
Sep 24 11:02:04 wandboard kernel: DMA free:160952kB min:1684kB low:2104kB high:2524kB active_anon:178884kB inactive_anon:144kB active_file:28kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:524288kB managed:177468kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:308kB slab_reclaimable:2880kB slab_unreclaimable:6376kB kernel_stack:1160kB pagetables:1028kB unstable:0kB bounce:0kB free_cma:159996kB writeback_tmp:0kB pages_scanned:75 all_unreclaimable? yes
Sep 24 11:02:04 wandboard kernel: lowmem_reserve[]: 0 0 0 0
Sep 24 11:02:04 wandboard kernel: DMA: 3486*4kB (UMC) 3056*8kB (UC) 2814*16kB (MC) 2395*32kB (UMC) 14*64kB (MC) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 160952kB
Sep 24 11:02:04 wandboard kernel: 90 total pagecache pages
Sep 24 11:02:04 wandboard kernel: 0 pages in swap cache
Sep 24 11:02:04 wandboard kernel: Swap cache stats: add 0, delete 0, find 0/0
Sep 24 11:02:04 wandboard kernel: Free swap = 0kB
Sep 24 11:02:04 wandboard kernel: Total swap = 0kB
Sep 24 11:02:04 wandboard kernel: 131072 pages of RAM
Sep 24 11:02:04 wandboard kernel: 40500 free pages
Sep 24 11:02:04 wandboard kernel: 4710 reserved pages
Sep 24 11:02:04 wandboard kernel: 1715 slab pages
Sep 24 11:02:04 wandboard kernel: 264131 pages shared
Sep 24 11:02:04 wandboard kernel: 0 pages swap cached
Sep 24 11:02:04 wandboard kernel: [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
Sep 24 11:02:04 wandboard kernel: [ 254] 0 254 623 154 3 0 0 upstart-udev-br
Sep 24 11:02:04 wandboard kernel: [ 269] 0 269 2377 156 6 0 -1000 systemd-udevd
Sep 24 11:02:04 wandboard kernel: [ 290] 103 290 889 139 5 0 0 dbus-daemon
Sep 24 11:02:04 wandboard kernel: [ 348] 0 348 826 46 4 0 0 bluetoothd
Sep 24 11:02:04 wandboard kernel: [ 363] 0 363 841 74 5 0 0 systemd-logind
Sep 24 11:02:04 wandboard kernel: [ 436] 109 436 705 86 5 0 0 avahi-daemon
Sep 24 11:02:04 wandboard kernel: [ 441] 101 441 7429 206 9 0 0 rsyslogd
Sep 24 11:02:04 wandboard kernel: [ 444] 109 444 675 55 5 0 0 avahi-daemon
Sep 24 11:02:04 wandboard kernel: [ 539] 0 539 1810 176 7 0 0 cups-browsed
Sep 24 11:02:04 wandboard kernel: [ 603] 0 603 486 45 3 0 0 upstart-socket-
Sep 24 11:02:04 wandboard kernel: [ 606] 0 606 621 185 5 0 0 upstart-file-br
Sep 24 11:02:04 wandboard kernel: [ 704] 0 704 845 29 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 705] 0 705 845 29 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 709] 0 709 845 29 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 710] 0 710 845 29 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 713] 0 713 845 29 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 734] 0 734 1471 120 6 0 -1000 sshd
Sep 24 11:02:04 wandboard kernel: [ 742] 0 742 565 45 5 0 0 cron
Sep 24 11:02:04 wandboard kernel: [ 998] 0 998 845 29 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 999] 0 999 407 28 5 0 0 getty
Sep 24 11:02:04 wandboard kernel: [ 1024] 1000 1024 676 47 4 0 0 ssh-agent
Sep 24 11:02:04 wandboard kernel: [ 8516] 0 8516 1729 222 7 0 0 cupsd
Sep 24 11:02:04 wandboard kernel: [13071] 0 13071 6958 244 11 0 0 console-kit-dae
Sep 24 11:02:04 wandboard kernel: [13136] 0 13136 8426 155 10 0 0 polkitd
Sep 24 11:02:04 wandboard kernel: [13482] 0 13482 2458 192 8 0 0 sshd
Sep 24 11:02:04 wandboard kernel: [13501] 1000 13501 2458 195 8 0 0 sshd
Sep 24 11:02:04 wandboard kernel: [13504] 1000 13504 1491 553 6 0 0 bash
Sep 24 11:02:04 wandboard kernel: [14291] 0 14291 1432 104 5 0 0 sudo
Sep 24 11:02:04 wandboard kernel: [14294] 0 14294 45100 41145 89 0 0 MY_PROCESS_NAME
Sep 24 11:02:04 wandboard kernel: Out of memory: Kill process 14294 (MY_PROCESS_NAME) score 316 or sacrifice child
Sep 24 11:02:04 wandboard kernel: Killed process 14294 (MY_PROCESS_NAME) total-vm:180400kB, anon-rss:164580kB, file-rss:0kB
私が正しく理解した場合（大きい場合）、order = 0は一度に1ページだけを要求することを意味し、これは断片化を犯人として除外するようです。レポート自体には、利用可能なページが多いと表示されます。どうなりますか？