많은 메모리가있는 Oom-killer (?!) - inotify

거대한 양의 폴더 (~ 2 000 000)에 inotify를 삽입하여 문제가 있습니다. 내가 8,388,608에 max_user_watches을 변경 :많은 메모리가있는 Oom-killer (?!) - inotify

echo 8388608 > /proc/sys/fs/inotify/max_user_watches

는 시계의 금액을 지원하기 위해, 서버는 3GB 무료 메모리가 있습니다. 그러나 몇 시간 (~ 15h) 후에 inotify 스크립트를 실행하면 죽게됩니다. 다음은/var/log/messages 추적입니다.

inotify.sh invoked oom-killer: gfp_mask=0xd0, order=1, oom_adj=0 
inotify.sh cpuset=/ mems_allowed=0 
Pid: 12488, comm: inotify.sh Not tainted 2.6.32-5-686 #1 
Call Trace: 
[<c1089534>] ? oom_kill_process+0x60/0x201 
[<c1089ab1>] ? __out_of_memory+0xf4/0x107 
[<c1089b1e>] ? out_of_memory+0x5a/0x7c 
[<c108c3c9>] ? __alloc_pages_nodemask+0x3ef/0x4d9 
[<c108c4bf>] ? __get_free_pages+0xc/0x17 
[<c102f06c>] ? copy_process+0xb7/0xf28 
[<c11028ad>] ? security_file_alloc+0xc/0xd 
[<c1030017>] ? do_fork+0x13a/0x2bc 
[<c10b182d>] ? fd_install+0x1e/0x3c 
[<c103b996>] ? recalc_sigpending+0xf/0x2e 
[<c103bcae>] ? sigprocmask+0x9d/0xbc 
[<c1001dae>] ? sys_clone+0x21/0x27 
[<c10030fb>] ? sysenter_do_call+0x12/0x28 
Mem-Info: 
DMA per-cpu: 
CPU 0: hi: 0, btch: 1 usd: 0 
CPU 1: hi: 0, btch: 1 usd: 0 
Normal per-cpu: 
CPU 0: hi: 186, btch: 31 usd: 0 
CPU 1: hi: 186, btch: 31 usd: 41 
HighMem per-cpu: 
CPU 0: hi: 186, btch: 31 usd: 0 
CPU 1: hi: 186, btch: 31 usd: 34 
active_anon:53061 inactive_anon:13287 isolated_anon:0 
active_file:2006 inactive_file:4143 isolated_file:0 
unevictable:0 dirty:272 writeback:0 unstable:0 
free:499244 slab_reclaimable:174921 slab_unreclaimable:25041 
mapped:1892 shmem:42 pagetables:240 bounce:0 
DMA free:3492kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15804kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:12080kB slab_unreclaimable:332kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes 
lowmem_reserve[]: 0 861 3032 3032 
Normal free:59488kB min:3720kB low:4648kB high:5580kB active_anon:0kB inactive_anon:0kB active_file:1092kB inactive_file:3380kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:881880kB mlocked:0kB dirty:1088kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:687604kB slab_unreclaimable:99832kB kernel_stack:952kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1211 all_unreclaimable? yes 
lowmem_reserve[]: 0 0 17366 17366 
HighMem free:1933996kB min:512kB low:2856kB high:5200kB active_anon:212244kB inactive_anon:53148kB active_file:6932kB inactive_file:13192kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2222948kB mlocked:0kB dirty:0kB writeback:0kB mapped:7564kB shmem:168kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:960kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no 
lowmem_reserve[]: 0 0 0 0 
DMA: 19*4kB 43*8kB 16*16kB 6*32kB 17*64kB 12*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3492kB 
Normal: 14406*4kB 99*8kB 1*16kB 3*32kB 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 59488kB 
HighMem: 31*4kB 14*8kB 8*16kB 2*32kB 2*64kB 1*128kB 2*256kB 1*512kB 1*1024kB 1*2048kB 471*4096kB = 1933996kB 
6194 total pagecache pages 
0 pages in swap cache 
Swap cache stats: add 0, delete 0, find 0/0 
Free swap = 1951736kB 
Total swap = 1951736kB 
786416 pages RAM 
560130 pages HighMem 
7712 pages reserved 
7694 pages shared 
275891 pages non-shared

스크립트를 종료하면 거의 2Gb의 여유 메모리가 생깁니다. 그래서 저는이 OOM을 정말로 이해하지 못합니다. 누군가 나를 도울 수 있습니까? 움 킬러가 page_fault_handler()와 관련된

#!/bin/bash 

INOTIFY_DIR="/data" 
inotifywait -rme modify,attrib,move,close_write,create,delete,delete_self $INOTIFY_DIR 2>> /datatest/inotify.log

출처

2013-11-20 BDR

: 스크립트는 다음과 같이 간단합니다. page_fault_handler가 가용성이 없어 페이지를 할당 할 수 없으면 커널 호출 page_fault_out_of_memory()을 통해 OOM 킬러를 호출합니다. 그런 다음 OOM 킬러 로직이 시작되어 메모리를 죽이고 정리하는 최상의 후보 프로세스를 선택합니다. 논리는 휴리스틱 방식을 따르므로 대부분의 킬러 블 프로세스를 찾아 메모리를 비우고 시스템을 활성 상태로 유지합니다.

OOM 킬러가 차지하는 이유는 전적으로 무료 페이지의 가용성에 근거합니다. 이는 모든 메모리 영역에서 페이지 할당 실패 일 수 있습니다. 사용 가능한 메모리가 충분히 크다고해서 다른 모든 영역에서 사용 가능한 메모리가 있다는 것을 의미하지는 않습니다. 등 ZONE_DMA, 낮은 MEM 등

, 내가 더 나은 내 inotify를 프로세스가 살해 이유를 이해

출처

2013-11-21 06:16:02 joe

이 명확한 설명 주셔서 감사 움 킬러 알고리즘에 대한 자세한 내용은 oom_kill.c에서 page_fault_out_of_memory()에서 봐. 무료 페이지의 비 가용성은 어떻게 피할 수 있습니까? Inotify 시계를 많이 넣는 더 좋은 방법이 있습니까? – BDR

음, 좋은 질문입니다. 당신의 직업을 수행하는 더 좋은 방법이 있는지 나는 모른다. 하지만 내 추측은 무리가 있어야한다는 것입니다. 2000000 개의 이상한 폴더에 inotify를 두는 것은 나에게 너무 좋지도 않으며 나에게 옳은 길도 아니다. 당신이 해결하려고하는 원래의 문제를 설명하는 것이 더 나은 해결책을 찾는 데 도움이 될 수 있습니다. 또는 별도의 질문을 게시하면 다른 사람이 대답 할 수 있습니다. – joe

나는 이전에 나의 원래 문제 [여기] (http://stackoverflow.com/questions/19813930/solution-for-migration-from-nfs-to-nas-gateway)를 게시합니다. 나는 2,000,000 개의 폴더에 inotify를 넣는 것이 좋지 않지만 아직 더 나은 해결책을 찾지 못한다는 것에 동의합니다. – BDR

많은 메모리가있는 Oom-killer (?!) - inotify

답변

관련 문제