리눅스 붐 상황


15

계속되는 oom & panic 상황이 해결되지 않았습니다. 시스템이 모든 램 (36GB)을 채우는 지 잘 모르겠습니다. 왜이 시스템이 이런 상황에 처하게 되었습니까? 32 비트 Linux 시스템의 lowmem 영역과 관련이 있다고 생각합니다. 커널 패닉 및 oom-killer의 로그를 어떻게 분석 할 수 있습니까?

친애하는,

커널 3.10.24

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0
Dec 27 09:19:05 2013 kernel: : [277622.359069] squid cpuset=/ mems_allowed=0
Dec 27 09:19:05 2013 kernel: : [277622.359074] CPU: 9 PID: 15533 Comm: squid Not tainted 3.10.24-1.lsg #1
Dec 27 09:19:05 2013 kernel: : [277622.359076] Hardware name: Intel Thurley/Greencity, BIOS 080016  10/05/2011
Dec 27 09:19:05 2013 kernel: : [277622.359078]  00000003 e377b280 e03c3c38 c06472d6 e03c3c98 c04d2d96 c0a68f84 e377b580
Dec 27 09:19:05 2013 kernel: : [277622.359089]  000042d0 00000003 00000000 e03c3c64 c04abbda e42bd318 00000000 e03c3cf4
Dec 27 09:19:05 2013 kernel: : [277622.359096]  000042d0 00000001 00000247 00000000 e03c3c94 c04d3d5f 00000001 00000042
Dec 27 09:19:05 2013 kernel: : [277622.359105] Call Trace:
Dec 27 09:19:05 2013 kernel: : [277622.359116]  [<c06472d6>] dump_stack+0x16/0x20
Dec 27 09:19:05 2013 kernel: : [277622.359121]  [<c04d2d96>] dump_header+0x66/0x1c0
Dec 27 09:19:05 2013 kernel: : [277622.359127]  [<c04abbda>] ? __delayacct_freepages_end+0x3a/0x40
Dec 27 09:19:05 2013 kernel: : [277622.359131]  [<c04d3d5f>] ? zone_watermark_ok+0x2f/0x40
Dec 27 09:19:05 2013 kernel: : [277622.359135]  [<c04d2f27>] check_panic_on_oom+0x37/0x60
Dec 27 09:19:05 2013 kernel: : [277622.359138]  [<c04d36d2>] out_of_memory+0x92/0x250
Dec 27 09:19:05 2013 kernel: : [277622.359144]  [<c04dd1fa>] ? wakeup_kswapd+0xda/0x120
Dec 27 09:19:05 2013 kernel: : [277622.359148]  [<c04d6cee>] __alloc_pages_nodemask+0x68e/0x6a0
Dec 27 09:19:05 2013 kernel: : [277622.359155]  [<c0801c1e>] sk_page_frag_refill+0x7e/0x120
Dec 27 09:19:05 2013 kernel: : [277622.359160]  [<c084b8c7>] tcp_sendmsg+0x387/0xbf0
Dec 27 09:19:05 2013 kernel: : [277622.359166]  [<c0469a2f>] ? put_prev_task_fair+0x1f/0x350
Dec 27 09:19:05 2013 kernel: : [277622.359173]  [<c0ba7d8b>] ? longrun_init+0x2b/0x30
Dec 27 09:19:05 2013 kernel: : [277622.359177]  [<c084b540>] ? tcp_tso_segment+0x380/0x380
Dec 27 09:19:05 2013 kernel: : [277622.359182]  [<c086d0da>] inet_sendmsg+0x4a/0xa0
Dec 27 09:19:05 2013 kernel: : [277622.359186]  [<c07ff3a6>] sock_aio_write+0x116/0x130
Dec 27 09:19:05 2013 kernel: : [277622.359191]  [<c0457acc>] ? hrtimer_try_to_cancel+0x3c/0xb0
Dec 27 09:19:05 2013 kernel: : [277622.359197]  [<c050b208>] do_sync_write+0x68/0xa0
Dec 27 09:19:05 2013 kernel: : [277622.359202]  [<c050caa0>] vfs_write+0x190/0x1b0
Dec 27 09:19:05 2013 kernel: : [277622.359206]  [<c050cbb3>] SyS_write+0x53/0x80
Dec 27 09:19:05 2013 kernel: : [277622.359211]  [<c08f72ba>] sysenter_do_call+0x12/0x22
Dec 27 09:19:05 2013 kernel: : [277622.359213] Mem-Info:
Dec 27 09:19:05 2013 kernel: : [277622.359215] DMA per-cpu:
Dec 27 09:19:05 2013 kernel: : [277622.359218] CPU    0: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359220] CPU    1: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359222] CPU    2: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359224] CPU    3: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359226] CPU    4: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359228] CPU    5: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359230] CPU    6: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359232] CPU    7: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359234] CPU    8: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359236] CPU    9: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359238] CPU   10: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359240] CPU   11: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359242] CPU   12: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359244] CPU   13: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359246] CPU   14: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359248] CPU   15: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359250] CPU   16: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359253] CPU   17: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359255] CPU   18: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359258] CPU   19: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359260] CPU   20: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359262] CPU   21: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359264] CPU   22: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359266] CPU   23: hi:    0, btch:   1 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359268] Normal per-cpu:
Dec 27 09:19:05 2013 kernel: : [277622.359270] CPU    0: hi:  186, btch:  31 usd:  34
Dec 27 09:19:05 2013 kernel: : [277622.359272] CPU    1: hi:  186, btch:  31 usd:  72
Dec 27 09:19:05 2013 kernel: : [277622.359274] CPU    2: hi:  186, btch:  31 usd:  40
Dec 27 09:19:05 2013 kernel: : [277622.359276] CPU    3: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359279] CPU    4: hi:  186, btch:  31 usd:  39
Dec 27 09:19:05 2013 kernel: : [277622.359281] CPU    5: hi:  186, btch:  31 usd:  49
Dec 27 09:19:05 2013 kernel: : [277622.359283] CPU    6: hi:  186, btch:  31 usd:  50
Dec 27 09:19:05 2013 kernel: : [277622.359285] CPU    7: hi:  186, btch:  31 usd:  25
Dec 27 09:19:05 2013 kernel: : [277622.359286] CPU    8: hi:  186, btch:  31 usd:  42
Dec 27 09:19:05 2013 kernel: : [277622.359289] CPU    9: hi:  186, btch:  31 usd:  39
Dec 27 09:19:05 2013 kernel: : [277622.359290] CPU   10: hi:  186, btch:  31 usd: 155
Dec 27 09:19:05 2013 kernel: : [277622.359293] CPU   11: hi:  186, btch:  31 usd:  56
Dec 27 09:19:05 2013 kernel: : [277622.359295] CPU   12: hi:  186, btch:  31 usd:   2
Dec 27 09:19:05 2013 kernel: : [277622.359297] CPU   13: hi:  186, btch:  31 usd: 162
Dec 27 09:19:05 2013 kernel: : [277622.359299] CPU   14: hi:  186, btch:  31 usd:  67
Dec 27 09:19:05 2013 kernel: : [277622.359301] CPU   15: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359303] CPU   16: hi:  186, btch:  31 usd:  68
Dec 27 09:19:05 2013 kernel: : [277622.359305] CPU   17: hi:  186, btch:  31 usd:  38
Dec 27 09:19:05 2013 kernel: : [277622.359307] CPU   18: hi:  186, btch:  31 usd:  56
Dec 27 09:19:05 2013 kernel: : [277622.359308] CPU   19: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359310] CPU   20: hi:  186, btch:  31 usd:  54
Dec 27 09:19:05 2013 kernel: : [277622.359312] CPU   21: hi:  186, btch:  31 usd:  35
Dec 27 09:19:05 2013 kernel: : [277622.359314] CPU   22: hi:  186, btch:  31 usd:   2
Dec 27 09:19:05 2013 kernel: : [277622.359316] CPU   23: hi:  186, btch:  31 usd:  60
Dec 27 09:19:05 2013 kernel: : [277622.359318] HighMem per-cpu:
Dec 27 09:19:05 2013 kernel: : [277622.359320] CPU    0: hi:  186, btch:  31 usd:  32
Dec 27 09:19:05 2013 kernel: : [277622.359322] CPU    1: hi:  186, btch:  31 usd:  52
Dec 27 09:19:05 2013 kernel: : [277622.359324] CPU    2: hi:  186, btch:  31 usd:   9
Dec 27 09:19:05 2013 kernel: : [277622.359326] CPU    3: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359328] CPU    4: hi:  186, btch:  31 usd: 125
Dec 27 09:19:05 2013 kernel: : [277622.359330] CPU    5: hi:  186, btch:  31 usd: 116
Dec 27 09:19:05 2013 kernel: : [277622.359332] CPU    6: hi:  186, btch:  31 usd: 126
Dec 27 09:19:05 2013 kernel: : [277622.359333] CPU    7: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359336] CPU    8: hi:  186, btch:  31 usd:  79
Dec 27 09:19:05 2013 kernel: : [277622.359338] CPU    9: hi:  186, btch:  31 usd:  34
Dec 27 09:19:05 2013 kernel: : [277622.359340] CPU   10: hi:  186, btch:  31 usd: 111
Dec 27 09:19:05 2013 kernel: : [277622.359341] CPU   11: hi:  186, btch:  31 usd: 144
Dec 27 09:19:05 2013 kernel: : [277622.359343] CPU   12: hi:  186, btch:  31 usd:  15
Dec 27 09:19:05 2013 kernel: : [277622.359345] CPU   13: hi:  186, btch:  31 usd: 166
Dec 27 09:19:05 2013 kernel: : [277622.359347] CPU   14: hi:  186, btch:  31 usd: 185
Dec 27 09:19:05 2013 kernel: : [277622.359349] CPU   15: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359351] CPU   16: hi:  186, btch:  31 usd:  58
Dec 27 09:19:05 2013 kernel: : [277622.359353] CPU   17: hi:  186, btch:  31 usd: 122
Dec 27 09:19:05 2013 kernel: : [277622.359356] CPU   18: hi:  186, btch:  31 usd: 170
Dec 27 09:19:05 2013 kernel: : [277622.359358] CPU   19: hi:  186, btch:  31 usd:   0
Dec 27 09:19:05 2013 kernel: : [277622.359360] CPU   20: hi:  186, btch:  31 usd:  30
Dec 27 09:19:05 2013 kernel: : [277622.359362] CPU   21: hi:  186, btch:  31 usd:  33
Dec 27 09:19:05 2013 kernel: : [277622.359364] CPU   22: hi:  186, btch:  31 usd:  28
Dec 27 09:19:05 2013 kernel: : [277622.359366] CPU   23: hi:  186, btch:  31 usd:  44
Dec 27 09:19:05 2013 kernel: : [277622.359371] active_anon:658515 inactive_anon:54399 isolated_anon:0
Dec 27 09:19:05 2013 kernel: : [277622.359371]  active_file:1172176 inactive_file:323606 isolated_file:0
Dec 27 09:19:05 2013 kernel: : [277622.359371]  unevictable:0 dirty:0 writeback:0 unstable:0
Dec 27 09:19:05 2013 kernel: : [277622.359371]  free:6911872 slab_reclaimable:29430 slab_unreclaimable:34726
Dec 27 09:19:05 2013 kernel: : [277622.359371]  mapped:45784 shmem:9850 pagetables:107714 bounce:0
Dec 27 09:19:05 2013 kernel: : [277622.359371]  free_cma:0
Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359384] lowmem_reserve[]: 0 573 36539 36539
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359395] lowmem_reserve[]: 0 0 287725 287725
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Dec 27 09:19:05 2013 kernel: : [277622.359406] lowmem_reserve[]: 0 0 0 0
Dec 27 09:19:05 2013 kernel: : [277622.359410] DMA: 3*4kB (U) 2*8kB (U) 4*16kB (U) 5*32kB (U) 2*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 2428kB
Dec 27 09:19:05 2013 kernel: : [277622.359422] Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB
Dec 27 09:19:05 2013 kernel: : [277622.359435] HighMem: 6672*4kB (M) 74585*8kB (UM) 40828*16kB (UM) 17275*32kB (UM) 3314*64kB (UM) 1126*128kB (UM) 992*256kB (UM) 585*512kB (UM) 225*1024kB (UM) 78*2048kB (UMR) 5957*4096kB (UM) = 27529128kB
Dec 27 09:19:05 2013 kernel: : [277622.359452] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Dec 27 09:19:05 2013 kernel: : [277622.359454] 1505509 total pagecache pages
Dec 27 09:19:05 2013 kernel: : [277622.359457] 4 pages in swap cache
Dec 27 09:19:05 2013 kernel: : [277622.359459] Swap cache stats: add 13, delete 9, find 0/0
Dec 27 09:19:05 2013 kernel: : [277622.359460] Free swap  = 35318812kB
Dec 27 09:19:05 2013 kernel: : [277622.359462] Total swap = 35318864kB
Dec 27 09:19:05 2013 kernel: : [277622.450529] 9699327 pages RAM
Dec 27 09:19:05 2013 kernel: : [277622.450532] 9471490 pages HighMem
Dec 27 09:19:05 2013 kernel: : [277622.450533] 342749 pages reserved
Dec 27 09:19:05 2013 kernel: : [277622.450534] 2864256 pages shared
Dec 27 09:19:05 2013 kernel: : [277622.450535] 1501243 pages non-shared
Dec 27 09:19:05 2013 kernel: : [277622.450538] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled

Dec 27 09:19:05 2013 kernel: : [277622.450538]

# cat /proc/meminfo
MemTotal:       37426312 kB
MemFree:        28328992 kB
Buffers:           94728 kB
Cached:          6216068 kB
SwapCached:            0 kB
Active:          6958572 kB
Inactive:        1815380 kB
Active(anon):    2329152 kB
Inactive(anon):   170252 kB
Active(file):    4629420 kB
Inactive(file):  1645128 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:      36828872 kB
HighFree:       28076144 kB
LowTotal:         597440 kB
LowFree:          252848 kB
SwapTotal:      35318864 kB
SwapFree:       35318860 kB
Dirty:                 0 kB
Writeback:             8 kB
AnonPages:       2463512 kB
Mapped:           162296 kB
Shmem:             36332 kB
Slab:             208676 kB
SReclaimable:     120872 kB
SUnreclaim:        87804 kB
KernelStack:        6320 kB
PageTables:        42280 kB
NFS_Unstable:          0 kB
Bounce:              124 kB
WritebackTmp:          0 kB
CommitLimit:    54032020 kB
Committed_AS:    3191916 kB
VmallocTotal:     122880 kB
VmallocUsed:       27088 kB
VmallocChunk:      29312 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10232 kB
DirectMap2M:      901120 kB

sysctl :

vm.oom_dump_tasks = 0
vm.oom_kill_allocating_task = 1
vm.panic_on_oom = 1

vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.drop_caches = 0
vm.highmem_is_dirtyable = 0
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256   32      32
vm.max_map_count = 65530
vm.min_free_kbytes = 3084
vm.mmap_min_addr = 4096
vm.nr_hugepages = 0
vm.nr_overcommit_hugepages = 0
vm.nr_pdflush_threads = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.percpu_pagelist_fraction = 0
vm.scan_unevictable_pages = 0
vm.stat_interval = 1
vm.swappiness = 30
vm.user_reserve_kbytes = 131072
vm.vdso_enabled = 1
vm.vfs_cache_pressure = 100

# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 292370
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 36728
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 292370
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

6
여러분,이 질문을 닫을 이유가 없습니다. 흥미로운 OOM 문제입니다.
Nils

1
다시 열어야 할 질문을 다시 한 번 말하였습니다.
seaquest

다음 행 "CPU 0 : hi : 0, btch : 1 usd : 0"에 대해 "hi", "btch"및 "usd"가 무엇을 의미하고 그들의 단위가 무엇인지 아는 사람이 있습니까?
waffleman

답변:


53

영역의 레이아웃이 다르게 수행되기 때문에 '슬레지 해머'방식은 64 비트 O / S (이것은 32 비트 임)로 업그레이드하는 것입니다.

자, 여기서 나는 당신이 왜 OOM을 경험했는지에 대답하려고 노력할 것입니다. 여기에는 여러 가지 요소가 있습니다.

  • 요청의 주문 크기와 커널이 특정 주문 크기를 처리하는 방법.
  • 선택된 구역.
  • 이 영역이 사용하는 워터 마크.
  • 영역에서 조각화.

OOM 자체를 보면 사용 가능한 충분한 메모리가 있지만 OOM-killer가 호출 되었습니까? 왜?


요청의 주문 크기와 커널이 특정 주문 크기를 처리하는 방법

커널은 순서대로 메모리를 할당합니다. '순서'는 요청이 작동하기 위해 충족되어야하는 연속 RAM 영역입니다. 순서는 알고리즘을 사용하여 크기 순서 (따라서 이름 순서)로 정렬됩니다 2^(ORDER + 12). 따라서 순서 0은 4096, 순서 1은 8192, 순서 2는 16384 등입니다.

커널은 '고차'(> PAGE_ALLOC_COSTLY_ORDER)로 간주되는 하드 코딩 된 값을 가지고 있습니다. 이것은 순서 4 이상입니다 (64kb 이상은 높은 순서입니다).

높은 순서는 낮은 순서와 다르게 페이지 할당에 대해 만족됩니다. 최신 커널에서 메모리를 확보하지 못하면 높은 할당량을 갖습니다.

  • 메모리 압축 조각화 루틴을 실행하여 메모리 조각 모음을 시도하십시오.
  • 요청을 충족시키기 위해 OOM-killer를 호출 하지 마십시오 .

주문 크기는 다음과 같습니다.

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

주문 3은 하위 요청 중에서 가장 높으며 (보시다시피) 요청을 충족시키기 위해 OOM 킬러를 호출합니다.

대부분의 사용자 공간 할당은 고차원 요청을 사용하지 않습니다. 일반적으로 인접한 메모리 영역이 필요한 커널입니다. 사용자 공간에서 hugepages를 사용하는 경우는 예외입니다. 그러나 여기서는 그렇지 않습니다.

귀하의 경우 순서 3 할당은 네트워크 스택에 패킷을 대기열에 넣고 자하는 커널에 의해 호출됩니다-32kb 할당이 필요합니다.

선택된 구역.

커널은 메모리 영역을 영역으로 나눕니다. x86에서 특정 메모리 영역은 특정 하드웨어에서만 처리 할 수 ​​있기 때문에 이러한 문제가 발생합니다. 예를 들어, 오래된 하드웨어는 'DMA'영역의 메모리에만 주소를 지정할 수 있습니다. 일부 메모리를 할당하려면 먼저 영역을 선택 하고이 영역의 사용 가능한 메모리 할당 결정을 수행합니다.

영역 선택 알고리즘에 대해 완전히 알고 있지는 않지만 일반적인 사용 사례는 DMA에서 할당하지 않고 일반적으로 요청을 충족시킬 수있는 가장 낮은 주소 지정 가능 영역을 선택하는 것입니다.

OOM 중에는 많은 영역 정보가 분리되어 있으며이 정보는에서 수집 할 수도 있습니다 /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

HighMem 영역이 64 비트에 존재하지 않기 때문에 DMA, Normal 및 HighMem 영역은 32 비트 플랫폼을 나타냅니다. 또한 64 비트 시스템에서 Normal은 4GB 이상으로 매핑되는 반면 32 비트에서는 최대 896Mb로 매핑됩니다 (그러나 커널은 이보다 작은 부분 만 관리한다고보고합니다 :-) managed:587540kB.

첫 번째 줄을 다시 보면서이 할당이 어디서 왔는지 알 수 있으며 gfp_mask=0x42d0어떤 유형의 할당이 수행되었는지 알려줍니다. 마지막 바이트 (0)는 이것이 일반 영역에서의 할당임을 나타냅니다. gfp 의미는 include / linux / gfp.h에 있습니다.

이 영역이 사용하는 워터 마크.

메모리가 부족한 경우 메모리를 회수하는 작업은 워터 마크로 지정됩니다. 그들은 여기에 나타난다 : min:3044kB low:3804kB high:4564kB. 사용 가능한 메모리가 '낮음'에 도달하면 '높음'임계 값을 초과 할 때까지 스와핑이 발생합니다. 메모리가 'min'에 도달하면 OOM-killer를 통해 메모리를 확보하기 위해 물건을 죽여야합니다.

영역에서 조각화.

커널은 특정 메모리 순서에 대한 요청을 충족시킬 수 있는지 확인하기 위해 사용 가능한 페이지 수와 각 주문에 대해 사용 가능한 수를 설명합니다. 에서 읽을 수 있습니다 /proc/buddyinfo. OOM-killer 보고서는 다음과 같이 buddyinfo도 추가로 뱉어냅니다.

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

메모리 할당이 충족 되려면 요청 된 주문 크기 또는 더 높은 할당에서 사용 가능한 메모리 가 있어야합니다 . 낮은 순서로 많은 양의 무료 데이터가 있고 높은 순서로없는 데이터는 메모리가 조각화되었음을 의미합니다. 매우 높은 순서의 할당을 받으면 사용 가능한 높은 순서의 페이지가 없기 때문에 사용 가능한 메모리가 많은 경우에도 만족할 수 없습니다. 커널은 하위 페이지를 많이 이동시켜 메모리를 조각 모음 할 수 있으므로 주소 지정 가능한 램 공간에 공백이 생기지 않습니다.

OOM-killer가 호출 되었습니까? 왜?

따라서 이러한 사항을 고려하면 다음과 같이 말할 수 있습니다.

  • 32kB 연속 할당이 시도되었습니다. 일반 영역에서.
  • 선택한 영역에 사용 가능한 메모리가 충분했습니다.
  • 주문 3, 5 및 6 메모리가 사용 가능했습니다 13*32kB (MR) 1*128kB (R) 1*256kB (R)

따라서 사용 가능한 메모리 있으면 다른 주문 요청을 충족시킬 있습니다. 어떻게 된 거예요?

음, 그 순서에 사용 가능한 여유 메모리 양을 확인하는 것보다 순서에서 할당하는 것이 더 많습니다. 커널은 총 여유 라인에서 모든 하위 순서에서 메모리를 효과적으로 빼고 남은 항목에 대해 최소 워터 마크 검사를 수행합니다.

귀하의 경우에 발생하는 일은 우리가해야 할 영역에 대한 여유 메모리를 확인하는 것입니다.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

이 여유 메모리 양은 min워터 마크 (3044) 와 비교하여 확인 됩니다. 따라서 기술적으로 말하자면, 요청한 할당을 수행 할 여유 메모리가 남아 있지 않습니다. 그리고 이것이 당신이 OOM-killer를 호출 한 이유입니다.


고정

두 가지 수정이 있습니다. 64 비트로 업그레이드하면 '정상'이 4GB에서 최대 36GB가되도록 영역 분할이 변경되므로 메모리 할당이 너무 세분화 될 수있는 영역으로 '기본 설정'하지 않습니다. PAE를 이미 사용하고 있기 때문에이 문제를 해결하는 더 많은 주소 지정 가능 메모리가있는 것이 아니라 선택한 영역에 더 많은 주소 지정 가능 메모리가 있다는 것입니다.

두 번째 방법 (내가 테스트 한 적이없는)은 커널이 메모리를보다 적극적으로 압축하도록 시도하는 것입니다.

값을 vm.extfrag_threshold500에서 100으로 변경하면 상위 할당을 수행하기 위해 메모리를 압축 할 가능성이 높습니다. 이전에는이 ​​값을 엉망으로 만들지 않았지만 조각화 인덱스가 무엇인지에 따라 달라집니다 /sys/kernel/debug/extfrag/extfrag_index. 나는 그 이상을 제공하는 것으로 보이는 것을 볼 수있는 새로운 커널이있는 상자를 가지고 있지 않습니다.

또는 일종의 크론 작업 (이것은 끔찍하고 추악합니다)을 실행하여 수동으로 메모리를 직접 압축 할 수 있습니다 /proc/sys/vm/compact_memory.

솔직히 말해서,이 문제를 피하기 위해 시스템을 조정하는 방법이 실제로는 없다고 생각합니다.이 방법으로 작동하는 메모리 할당 자의 특성. 사용하는 플랫폼의 아키텍처를 변경하는 것이 근본적으로 해결 가능한 유일한 솔루션 일 것입니다.


현재 64 비트로 들어가는 것은 불가능합니다. 오류가 발생하지 않도록 시스템을 조정해야합니다.
seaquest

4
이것은 멋진 답변입니다. 공감대를 가지십시오 :)
wzzrd

안녕하세요 Mlfe, 훌륭한 답변입니다. 귀하의 게시물에서이 부분이 궁금합니다. "커널은 총 여유 라인에서 모든 하위 순서에서 메모리를 효과적으로 빼고 남은 항목에 대해 최소 워터 마크 검사를 수행합니다." -내가 통과 할 수있는 관련 소스 코드가 있습니까? 글쎄, 나는 많은 OOM 문제를 다루었지만 소스 에서이 논리를 보지 못했습니다. 아마도, 나는 그리워했다. 어쨌든 어디서 봅니까? oom_kill.c? 아니면 다른 것?
Soham Chakraborty

2
코드는 mm / page_alloc.c에 있으며 __zone_watermark_ok
Matthew Ife

@SohamChakraborty이 내용에 관심이 있다면 여기에서와 같이 제공된 OOM-killer 출력의 스택 추적을 따라 커널에서 OOM을 일으키는 원인을 알아낼 수 있습니다.
Matthew Ife

5

시작 꺼짐 : 당신이해야 정말 64 비트 운영 체제에 대한 이동합니다. 여기서 32 비트를 유지해야 할 이유가 있습니까?

시스템을 더 자세히 보지 않고, 바람직하게는 실패 할 때까지이 문제를 진단하기가 어렵 기 때문에 내 (빠른) 게시물은 일반적으로 32 비트 시스템의 메모리 문제를 대상으로합니다. 64 비트를 사용하면이 모든 것이 사라질 것이라고 언급 했습니까?

문제는 세 가지입니다.

우선 PAE 커널에서도 프로세스 당 주소 공간은 4GiB [1]로 제한됩니다. 이는 오징어 인스턴스가 프로세스 당 4GiB 이상의 RAM을 사용할 수 없음을 의미합니다. 나는 오징어에 익숙하지 않지만 이것이 주 프록시 서버라면 어쨌든 충분하지 않을 수 있습니다.

둘째, 방대한 양의 RAM이있는 32 비트 시스템에서 ZONE_NORMAL이라는 메모리의 많은 메모리가 ZONE_HIGHMEM에서 메모리를 사용하는 데 필요한 데이터 구조를 저장하는 데 사용됩니다. 커널이 자체 목적으로 사용하는 메모리는 항상 ZONE_NORMAL (즉, 첫 번째 1Gi-ish)에 있어야하므로 이러한 데이터 구조는 ZONE_HIGHMEM 자체로 이동할 수 없습니다. ZONE_HIGHMEM에 많은 메모리가 있으면 (많은 경우에) 커널이 ZONE_HIGHMEM을 관리하기 위해 ZONE_NORMAL에서 더 많은 메모리를 필요로하기 때문에 더 많은 문제가됩니다. ZONE_NORMAL의 사용 가능한 메모리 양이 마르면 ZONE_NORMAL은 32 비트 시스템에서 많은 일이 발생 하기 때문에 일부 작업에서 시스템이 실패 할 수 있습니다. 모든 커널 관련 메모리 작업 (예 :;)

셋째, ZONE_NORMAL에 일부 메모리가 남아 있어도 (로그를 자세히 보지 않았 음) 일부 메모리 작업에는 조각화되지 않은 메모리가 필요합니다. 예를 들어, 모든 메모리가 실제로 작은 조각으로 조각난 경우 그보다 더 많은 작업이 실패합니다. [3] 로그를 간단히 살펴보면 ZONE_DMA 및 ZONE_NORMAL에서 상당히 많은 조각화가 나타납니다.

편집 : 위의 Mlfe의 답변에는 이것이 어떻게 작동하는지에 대한 훌륭한 설명이 있습니다.

다시 한 번 : 64 비트 시스템에서 모든 메모리는 ZONE_NORMAL에 있습니다. 64 비트 시스템에는 HIGHMEM 영역이 없습니다. 문제 해결됨.

편집 : 여기를 살펴보면 [4] oom-killer에게 중요한 프로세스 만 남겨 두도록 지시 할 수 있습니다. 그래도 모든 것을 해결할 수는 없지만 시도해 볼 가치가 있습니다.

[1] http://en.wikipedia.org/wiki/Physical_address_extension#Design

[2] http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html / Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_ 데이터베이스 / sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_er_huhtmlem_

[3] http://bl0rg.krunch.be/oom-frag.html

[4] http://lwn.net/Articles/317814/


1
언뜻보기에 normal은이 할당을 커밋하기에 충분한 여유 메모리를 가지고 있지만 메모리는 일반 영역 (gfp_mask 참조)에서 할당되고 있습니다. 이에 대한 실제 설명이 있지만 내 게시물을 꽤 오래 편집해야합니다.
Matthew Ife

4

@MIfe는 이미 커널에서 메모리 할당을 처리하는 방법에 대한 훌륭한 기록을 제공했으며 64 비트 OS로 전환하는 등의 적절한 솔루션과 /proc/sys/vm/compact_memoryin을 통해 수동 메모리 압축과 같은 거친 해킹을 제공 했습니다 cron.

내 2 센트는 당신을 도울 수있는 또 다른 해결 방법이 될 것입니다. 커널 백 트레이스에
있음을 알았습니다 tcp_tso_segment.

# ethtool -K ethX tso off gso off lro off

mm더 낮은 차수를 사용하도록하여 압력을 줄일 수 있습니다 .

추신 . 모든 오프로드 목록은 다음을 통해 얻을 수 있습니다.# ethtool -k ethX


2
이것은 훌륭한 제안입니다. 당신에게 공감하십시오.
Matthew Ife

이 정보는 아주 좋은 포인터입니다. 또한 tso의 효과를 검사합니다.
seaquest

3

패닉은 sysctl "vm.panic_on_oom = 1"이 설정되어 있기 때문입니다. 시스템을 재부팅하면 시스템이 정상 상태로 돌아갑니다. sysctl.conf에서이를 변경할 수 있습니다.

바로 상단에 오징어가 oom killer를 호출했습니다. 오징어 구성과 최대 메모리 사용량을 확인하거나 64 비트 OS로 이동할 수 있습니다.

/ proc / meminfo는 사용중인 메모리 영역이 높으므로 36GB 메모리를 가진 32 비트 커널을 실행하고 있습니다. 또한 일반 영역에서 오징어의 메모리 요구를 충족시키기 위해 커널이 성공적으로 982 페이지를 스캔했음을 알 수 있습니다.

pages_scanned:982 all_unreclaimable? yes
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.