저는 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의 주석에는 프로세스에 다음이 있다고 나와 있습니다.총 크기 180MB;이것은 300MB보다 훨씬 적기 때문에 실행하기 전에는 무료라고 합니다. oom-killer를 트리거하는 것은 이 프로세스 자체의 메모리 요청입니다.
(확실히 프로세스를 죽이는 움킬러입니다. 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에 대한 호출이 표시됨) 먼저 출력이 180MB 프로세스 크기와 일치하는 것으로 보입니다. 두 번째는 프로세스가 이전에 실행되었을 때입니다. 완전 망했습니다. 할당량은 약 15MB입니다.
gdb에서 프로세스를 실행하고 종료될 때까지 가능한 한 오랫동안 중지하면 다음과 같습니다.
- /proc/meminfo의 LowFree 숫자는 여전히 약 230MB입니다.
- /proc/meminfo의 다른 숫자 중 어느 것도 추가 메모리가 사용되고 있음을 나타내지 않는 것 같습니다. (예: slab은 여전히 약 10MB이므로 프로세스가 어떻게든 커널이 많은 메모리를 할당하도록 유발하지 않는 것 같습니다.)
- ps는 프로세스의 vsize가 약 165MB라고 보고합니다(이는 15MB 할당으로 인해 180MB가 되는 것과 일치하며 이는 분명히 oom-killer가 프로세스를 종료할 때 발생하는 현상입니다).
- gdb는
info proc mappings나에게 의심스러워 보이는 어떤 것도 표시하지 않습니다. [추가하도록 편집됨:]와는 별개로저것- 나열되는 영역 중 하나에는 와 같은 이름이 있고
[stack:14958], 숫자는 내 스레드 중 하나의 LWP ID이며, 코드의 모든 큰 메모리 할당이 힙을 통해malloc또는 힙에서 이루어지더라도 크기는 약 130MB인 것 같습니다new. 그런 영역이 있지만heap훨씬 작습니다. - 프로세스를 추적해 보면 이 모든 큰 메모리 할당이 실제로 배후에 매핑되어 있음을 알 수 있습니다. 이 설명만으로도 충분하다고 생각합니다(따라서 오해의 소지가 있는 "스택" 이름). 그래서 확실하지 않습니다. (이러한 mmap 호출에 의해 반환된 메모리 블록이 이 영역 내에 있다는 것을 확인했습니다.)
- 나열되는 영역 중 하나에는 와 같은 이름이 있고
(아마도 관련이 있을 수 있습니다: 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은 한 번에 한 페이지만 요청한다는 의미이며, 이는 조각화를 범인으로 배제하는 것 같습니다. 보고서 자체에는 사용 가능한 페이지가 많다고 표시됩니다.어떻게 되어가나요?