☰

OOM 킬러는 ulimit(ed)를 어떻게 처리합니까?

tag-icon • tag-icon memory out-of-memory memory-leaks
OOM 킬러는 ulimit(ed)를 어떻게 처리합니까?

MongoDB 클러스터를 사용하고 있습니다. 여러 번의 OOM 킬러 이후 저는 mongoDB의 메모리를 4G RAM으로 제한하기로 결정했습니다. 몇 시간 후 그는 OOM으로 인해 다시 사망했습니다. 그래서 제 질문은 MongoDB에 관한 것이 아니라 Linux의 메모리 관리에 관한 것입니다. OOM이 시작되기 몇 분 전의 HTOP입니다. 여기에 이미지 설명을 입력하세요.

VIRT에는 4.2T가 있고 RES에는 11M만 있는 이유는 무엇입니까?

몇 가지 유용한 정보:

root@mongodb: pmap -d 24059
....
mapped: 4493752480K    writeable/private: 2247504740K    shared: 2246203932K

이것은 dmesg 로그입니다:

[617568.768581] bash invoked oom-killer: gfp_mask=0x26000c0, order=2, oom_score_adj=0
[617568.768585] bash cpuset=/ mems_allowed=0
[617568.768590] CPU: 0 PID: 4686 Comm: bash Not tainted 4.4.0-83-generic #106-Ubuntu
[617568.768591] Hardware name: Xen HVM domU, BIOS 4.2.amazon 02/16/2017
[617568.768592]  0000000000000286 00000000c18427a2 ffff8800a41f7b10 ffffffff813f9513
[617568.768595]  ffff8800a41f7cc8 ffff8800ba798000 ffff8800a41f7b80 ffffffff8120b53e
[617568.768597]  ffffffff81cd6fd7 0000000000000000 ffffffff81e677e0 0000000000000206
[617568.768600] Call Trace:
[617568.768605]  [<ffffffff813f9513>] dump_stack+0x63/0x90
[617568.768609]  [<ffffffff8120b53e>] dump_header+0x5a/0x1c5
[617568.768613]  [<ffffffff81192ae2>] oom_kill_process+0x202/0x3c0
[617568.768614]  [<ffffffff81192f09>] out_of_memory+0x219/0x460
[617568.768617]  [<ffffffff81198ef8>] __alloc_pages_slowpath.constprop.88+0x938/0xad0
[617568.768620]  [<ffffffff81199316>] __alloc_pages_nodemask+0x286/0x2a0
[617568.768622]  [<ffffffff811993cb>] alloc_kmem_pages_node+0x4b/0xc0
[617568.768625]  [<ffffffff8107eafe>] copy_process+0x1be/0x1b20
[617568.768627]  [<ffffffff811c1e44>] ? handle_mm_fault+0xcf4/0x1820
[617568.768631]  [<ffffffff81349133>] ? security_file_alloc+0x33/0x50
[617568.768633]  [<ffffffff810805f0>] _do_fork+0x80/0x360
[617568.768635]  [<ffffffff81080979>] SyS_clone+0x19/0x20
[617568.768639]  [<ffffffff81840b72>] entry_SYSCALL_64_fastpath+0x16/0x71
[617568.768641] Mem-Info:
[617568.768644] active_anon:130 inactive_anon:192 isolated_anon:0
                 active_file:197 inactive_file:202 isolated_file:20
                 unevictable:915 dirty:0 writeback:185 unstable:0
                 slab_reclaimable:27072 slab_unreclaimable:5594
                 mapped:680 shmem:19 pagetables:1974772 bounce:0
                 free:18777 free_pcp:1 free_cma:0
[617568.768646] Node 0 DMA free:15904kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15988kB managed:15904kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[617568.768651] lowmem_reserve[]: 0 3745 7966 7966 7966
[617568.768654] Node 0 DMA32 free:49940kB min:5332kB low:6664kB high:7996kB active_anon:512kB inactive_anon:756kB active_file:776kB inactive_file:800kB unevictable:2828kB isolated(anon):0kB isolated(file):80kB present:3915776kB managed:3835092kB mlocked:2828kB dirty:0kB writeback:740kB mapped:2360kB shmem:52kB slab_reclaimable:69736kB slab_unreclaimable:8316kB kernel_stack:2272kB pagetables:3674424kB unstable:0kB bounce:0kB free_pcp:4kB local_pcp:4kB free_cma:0kB writeback_tmp:0kB pages_scanned:6592 all_unreclaimable? no
[617568.768658] lowmem_reserve[]: 0 0 4221 4221 4221
[617568.768660] Node 0 Normal free:9264kB min:6008kB low:7508kB high:9012kB active_anon:8kB inactive_anon:12kB active_file:12kB inactive_file:8kB unevictable:832kB isolated(anon):0kB isolated(file):0kB present:4587520kB managed:4322680kB mlocked:832kB dirty:0kB writeback:0kB mapped:360kB shmem:24kB slab_reclaimable:38552kB slab_unreclaimable:14060kB kernel_stack:1680kB pagetables:4224664kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:14432 all_unreclaimable? yes
[617568.768664] lowmem_reserve[]: 0 0 0 0 0
[617568.768667] Node 0 DMA: 0*4kB 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M) 3*4096kB (M) = 15904kB
[617568.768675] Node 0 DMA32: 11687*4kB (UME) 410*8kB (UME) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 50028kB
[617568.768682] Node 0 Normal: 1878*4kB (UME) 1*8kB (H) 1*16kB (H) 0*32kB 1*64kB (H) 1*128kB (H) 2*256kB (H) 0*512kB 1*1024kB (H) 0*2048kB 0*4096kB = 9264kB
[617568.768691] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
[617568.768692] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[617568.768693] 1275 total pagecache pages
[617568.768694] 249 pages in swap cache
[617568.768695] Swap cache stats: add 30567734, delete 30567485, find 17605568/26043265
[617568.768696] Free swap  = 7757000kB
[617568.768697] Total swap = 8388604kB
[617568.768698] 2129821 pages RAM
[617568.768699] 0 pages HighMem/MovableOnly
[617568.768699] 86402 pages reserved
[617568.768700] 0 pages cma reserved
[617568.768701] 0 pages hwpoisoned
[617568.768702] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[617568.768706] [  402]     0   402    25742      324      18       3       73             0 lvmetad
[617568.768708] [  440]     0   440    10722      173      22       3      301         -1000 systemd-udevd
[617568.768710] [  836]     0   836     4030      274      11       3      218             0 dhclient
[617568.768711] [  989]     0   989     1306      400       8       3       58             0 iscsid
[617568.768713] [  990]     0   990     1431      880       8       3        0           -17 iscsid
[617568.768715] [  996]   104   996    64099      210      28       3      351             0 rsyslogd
[617568.768716] [ 1001]     0  1001   189977        0      33       4      839             0 lxcfs
[617568.768718] [ 1005]   107  1005    10746      298      25       3      164          -900 dbus-daemon
[617568.768720] [ 1031]     0  1031     1100      289       8       3       36             0 acpid
[617568.768721] [ 1033]     0  1033    16380      290      36       3      203         -1000 sshd
[617568.768723] [ 1035]     0  1035     7248      341      18       3      180             0 systemd-logind
[617568.768725] [ 1038]     0  1038    68680        0      36       3      251             0 accounts-daemon
[617568.768726] [ 1041]     0  1041     6511      376      17       3       57             0 atd
[617568.768728] [ 1046]     0  1046    35672        0      27       5     1960             0 snapd
[617568.768729] [ 1076]     0  1076     3344      202      11       3       45             0 mdadm
[617568.768731] [ 1082]     0  1082    69831        0      38       4      342             0 polkitd
[617568.768733] [ 1183]     0  1183     4868      357      14       3       73             0 irqbalance
[617568.768734] [ 1192]   113  1192    27508      399      24       3      159             0 ntpd
[617568.768735] [ 1217]     0  1217     3665      294      12       3       39             0 agetty
[617568.768737] [ 1224]     0  1224     3619      385      12       3       38             0 agetty
[617568.768739] [10996]  1000 10996    11312      414      25       3      206             0 systemd
[617568.768740] [10999]  1000 10999    15306        0      33       3      475             0 (sd-pam)
[617568.768742] [14125]     0 14125    23842      440      50       3      236             0 sshd
[617568.768743] [14156]  1000 14156    23842        0      48       3      247             0 sshd
[617568.768745] [14157]  1000 14157     5359      425      15       3      512             0 bash
[617568.768747] [16461]   998 16461    11312      415      26       3      216             0 systemd
[617568.768748] [16465]   998 16465    15306        0      33       3      483             0 (sd-pam)
[617568.768750] [16470]   998 16470     4249        0      13       3       39             0 nrsysmond
[617568.768751] [16471]   998 16471    63005      109      26       3      891             0 nrsysmond
[617568.768753] [17374]   999 17374   283698        0      90       4     6299             0 XXX0
[617568.768754] [22123]     0 22123     8819      305      20       3       72             0 systemd-journal
[617568.768756] [28957]     0 28957     6932      379      17       3       90             0 cron
[617568.768758] [24059]   114 24059 1123438119        0 1973782    4288   127131             0 mongod
[617568.768760] [ 4684]     0  4684    12856      433      29       3      117             0 sudo
[617568.768761] [ 4685]     0  4685    12751      387      30       3      105             0 su
[617568.768763] [ 4686]     0  4686     5336      312      15       3      493             0 bash
[617568.768765] [18016]   999 18016     1127      145       7       3       25             0 sh
[617568.768766] [18017]   999 18017     9516      212      20       4      611             0 XXX1
[617568.768767] [18020]   999 18020     1127      120       8       3       24             0 sh
[617568.768769] [18021]   999 18021     9355      299      20       3      415             0 check-disk-usag
[617568.768770] [18024]     0 18024    12235      353      27       3      123             0 cron
[617568.768772] [18025]  1000 18025     2819      345      10       3       63             0 XXX2
[617568.768773] Out of memory: Kill process 24059 (mongod) score 508 or sacrifice child
[617568.772529] Killed process 24059 (mongod) total-vm:4493752476kB, anon-rss:0kB, file-rss:0kB

누군가 이 문제를 설명할 수 있나요?

예를 들어 MongoDB가 11M RES 메모리만 사용할 때 RAM이 가득 찬 이유는 무엇입니까?
VIRT도 RAM을 사용하나요? 그렇다면 어떤 가상 주소 공간이 있을까요? OOM이 왜 죽였나요? 페이지 테이블이 너무 많습니다(스왑이 거의 비어 있는 것을 볼 수 있음).

편집: 이 사람은 상단 정렬을 요청했습니다.

top을 실행하고 f를 누른 다음 %MEM을 강조 표시하고 s를 눌러 정렬 순서를 설정합니다. 출력을 게시합니다. @ramansailopal

물론 이것은 다른 processID이지만 여전히 동일해야 합니다.

산출:

pu(s):  0.3%us,  0.3%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.3%st
Mem:   3840468k total,  3799364k used,    41104k free,    12220k buffers
Swap:        0k total,        0k used,        0k free,    70736k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  SWAP DATA COMMAND
16213 mongodb   20   0 3443g 176m 9408 S  0.7  4.7 211:22.66 3.4t 3.9g mongod
 7706 sensu     20   0  661m  23m  804 S  0.0  0.6  20:20.92 637m 588m sensu-client
27120 ubuntu    20   0  595m  13m 7240 S  0.0  0.4   0:00.06 581m 569m mongo
24964 ubuntu    20   0 25936 8464 1708 S  0.0  0.2   0:00.54  17m 6736 bash
13858 ubuntu    20   0 26064 7620  728 S  0.0  0.2   0:00.75  18m 6864 bash

답변1

세 가지 사실의 조합으로 인해 oom 문제가 발생할 수 있습니다.작은 페이지 크기,대형 VIRT,페이지 테이블. 로그에는 거의 모든 RAM이 프로세스 메모리가 아닌 페이지 테이블에서 사용된다는 사실이 명확하게 나와 있습니다(예: 상주 페이지가 아닌 페이지는 대부분 스왑을 위해 푸시됩니다).

x86_64/x86 페이지 테이블의 나쁜 점은 정확히 동일한 공유 메모리 영역을 매핑하는 여러 프로세스가 있을 때 해당 프로세스가 그대로 유지된다는 것입니다.분리페이지 테이블. 따라서 프로세스가 1TB(VIRT에 포함됨)를 매핑하면 커널은 1GB의 페이지 테이블을 생성합니다( top프로세스에 속하는 것으로 계산되지 않으므로 전혀 표시되지 않음). 그러나 100개의 프로세스가 동일한 1TB 영역을 매핑하는 경우 동일한 메타데이터를 중복 저장하기 위해 100GB의 RAM을 차지하게 됩니다!

단일 프로세스에 대한 VIRT의 양은 단순히 파일(이름 또는 "익명")을 열고 매핑함으로써 발생할 수 있지만 다른 많은 설명이 있을 수 있습니다.

oom killer는 프로세스를 종료할 때 페이지 테이블 크기를 고려하지 않는 것 같습니다. 귀하의 경우, 분명히 mongodb는 RES 사용 측면에서 oom Kill의 주요 후보입니다. 얻은 메모리는 최소화되었지만 시스템에는 선택의 여지가 없었으므로 가능한 모든 것을 종료했습니다.

문제를 피하는 가장 확실한 방법은 다음을 사용하는 것입니다.큰 페이지, mongodb만 이를 지원하는 경우(투명 거대 페이지 사용을 권장하지 않지만 일반 불투명 거대 페이지를 고려합니다). 대략적인 검색 결과, 슬프게도 mongodb는 불투명한 hugepages도 지원하지 않는 것으로 나타났습니다.

또 다른 접근 방식은 생성 프로세스 수를 제한하거나 어떤 방식으로든 해당 VIRT 크기를 줄이는 것입니다.

관련 정보