램 킬러는 많은 양의 여유 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 시간이고 이것들은 홀수 값을 갖는 유일한 두 가지 프로세스입니다. 내 생각에는 "다른 것"이 진행되고 있으며, 이러한 의미가없는 가치와 관련이있을 수 있습니다. 특히, 시스템 은 메모리가 부족 하다고 생각 하지만 실제로는 그렇지 않습니다. 결국이 시스템에서 이론상 최대 값이 400 % 일 때 rsyslogd가 55383984 % CPU를 일관되게 사용하고 있다고 생각합니다.

이것은 768MB의 RAM이있는 최신 CentOS 6 설치 (6.2)입니다. 왜 이런 일이 발생하는지 알아내는 방법에 대한 제안은 감사하겠습니다!

편집 : VM을 첨부합니다. sysctl 튜너 블 .. 나는 swappiness (100로 분명하게 만들었습니다)를 가지고 놀았으며 버퍼와 캐시를 덤프 하는 완전히 끔찍한 스크립트를 실행하고 있습니다 (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 log dump를 보았고 그 그래프의 정확성에 의문을 갖습니다. 첫 번째 '노드 0 DMA32'라인에 주목하십시오. 그것은 말한다 free:3376kB, min:3448kB하고 low:4308kB. 자유 값이 낮은 값 아래로 떨어질 때마다 kswapd는 해당 값이 높은 값 위로 돌아올 때까지 물건을 교환하기 시작합니다. 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이 그런 식으로 행동하는 것을 본 적이 없다. 범인은 자바 앱과 브라우저와 같은 GUI 기반 앱일 가능성이 높습니다.