☰

Linux oom 상황(32비트 커널)

tag-icon • tag-icon linux kernel-panic oom oom-killer
Linux oom 상황(32비트 커널)

해결되지 않은 지속적인 붐 및 패닉 상황이 발생했습니다. 시스템이 모든 RAM(36GB)을 채우는지 잘 모르겠습니다. 이 시스템이 왜 이런 붐 상황을 촉발시켰나요? 나는 그것이 32비트 리눅스 시스템의 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

답변1

하지만 '큰 망치' 접근 방식은 영역의 레이아웃이 다르게 수행되므로 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-killer를 호출합니다.

대부분의 사용자 공간 할당은 상위 요청을 사용하지 않습니다. 일반적으로 연속적인 메모리 영역이 필요한 커널입니다. 이에 대한 예외는 사용자 공간이 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

DMA, Normal 및 HighMem 영역은 32비트 플랫폼을 나타냅니다. 왜냐하면 HighMem 영역은 64비트에 존재하지 않기 때문입니다. 또한 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 보고서는 여기에 표시된 대로 친구 정보도 추가로 뱉어냅니다.

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

거기에서 메모리 할당이 충족되려면~ 해야 하다요청된 주문 크기 또는 더 높은 할당량으로 사용 가능한 여유 메모리가 있어야 합니다. 낮은 순서에는 사용 가능한 데이터가 많고 높은 순서에는 비어 있는 데이터가 없다는 것은 메모리가 조각화되었음을 의미합니다. 매우 높은 순서 할당을 얻는 경우 사용 가능한 상위 페이지가 없기 때문에 만족하지 못할 가능성이 있습니다(사용 가능한 메모리가 많더라도). 커널은 주소 지정 가능한 RAM 공간에 공백이 생기지 않도록 많은 하위 페이지를 이동하여 메모리 조각 모음(메모리 압축이라고 함)을 수행할 수 있습니다.

OOM 킬러가 호출되었나요? 왜?

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

  • 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으로 변경하면 상위 할당을 존중하기 위해 메모리를 압축할 가능성이 높아집니다. 하지만 저는 이전에 이 값을 망쳐본 적이 없습니다. 또한 .NET에서 사용할 수 있는 조각화 인덱스가 무엇인지에 따라 달라집니다 /sys/kernel/debug/extfrag/extfrag_index. 현재로서는 이보다 더 많은 것을 제공하는 것이 무엇인지 확인할 수 있을 만큼 새로운 커널이 포함된 상자가 없습니다.

또는 /proc/sys/vm/compact_memory.

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

답변2

시작부터: 해야 합니다정말64비트 운영 체제를 선택하세요. 여기서 32비트를 유지해야 하는 타당한 이유가 있습니까?

시스템을 더 자세히 살펴보지 않고는 이 문제를 진단하기 어렵습니다. 가급적이면 시스템이 실패할 무렵에 제 (빠른) 게시물은 일반적으로 32비트 시스템의 메모리 문제를 겨냥하고 있습니다. 64비트로 전환하면 이 모든 것이 사라질 것이라고 말씀드렸나요?

문제는 세 가지입니다.

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

둘째, 방대한 양의 RAM을 갖춘 32비트 시스템에서는 'ZONE_NORMAL'이라는 공간에 많은 메모리를 사용하여 ZONE_HIGHMEM에 메모리를 사용하는데 필요한 데이터 구조를 저장합니다. 커널이 자체 목적으로 사용하는 메모리는 항상 ZONE_NORMAL(즉, 첫 번째 1GiB-ish)에 있어야 하기 때문에 이러한 데이터 구조는 ZONE_HIGHMEM 자체로 이동할 수 없습니다. ZONE_HIGHMEM에 메모리가 많을수록(귀하의 경우에는 많이) 문제가 더 커집니다. 왜냐하면 커널이 ZONE_HIGHMEM을 관리하기 위해 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.html그리고https://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_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit _Architecture_and_the_hugemem_Kernel.html

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

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

답변3

@MIfe는 이미 제공되었습니다.커널의 메모리 할당이 처리되는 방법에 대한 훌륭한 글입니다.또한 64비트 OS로 전환하는 것과 같은 적절한 솔루션과 .NET /proc/sys/vm/compact_memory을 통한 수동 메모리 압축과 같은 불쾌한 해킹을 제공했습니다 cron.

내 2센트가 도움이 될 수 있는 또 다른 해결 방법이 될 것입니다. 커널 역추적에 다음이
있는 것을 확인했습니다 .tcp_tso_segment

# ethtool -K ethX tso off gso off lro off

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

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

답변4

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

맨 위에는 오징어 호출 옴 킬러가 있습니다. 오징어 구성과 최대 메모리 사용량을 확인하거나 64비트 OS로 이동할 수도 있습니다.

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

pages_scanned:982 all_unreclaimable? yes

관련 정보