Linuxの状況


15

継続的なoom&panicの状況は未解決です。システムがすべてのRAM(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の問題です。
ニルス

1
質問を言い換えて、もう一度開きます。
シークエスト14

次の行「CPU 0:hi:0、btch:1 usd:0」について、誰もが「hi」、「btch」、「usd」の意味と単位を知っていますか?
ワッフルマン14

回答:


52

ただし、「大ハンマー」アプローチは、ゾーンのレイアウトが異なるため、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

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

メモリの割り当てが満たされるためには、要求されたオーダーサイズ以上の空きメモリが使用可能である必要あります。低次では多くの空きデータがあり、高次では空きデータがない場合は、メモリが断片化しています。非常に高次の割り当てを取得した場合、使用可能な高次ページがないために満たされない可能性があります(多くの空きメモリがあっても)。カーネルは、アドレス指定可能なRAMスペースにギャップを残さないように、多くの低次ページを移動することでメモリを最適化できます(これはメモリ圧縮と呼ばれます)。

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を起動した理由です。


修正

2つの修正があります。64ビットにアップグレードすると、「通常」が4GBから最大36GBになるようにゾーンのパーティションが変更されるため、非常に断片化される可能性のあるゾーンへのメモリ割り当てが「デフォルト」になりません。(PAEを既に使用しているため)この問題を解決するアドレス可能なメモリが増えているわけではなく、選択したゾーンのアドレス可能なメモリが多いだけです。

2番目の方法(これまでテストしたことはありません)は、カーネルにメモリをより積極的に圧縮させることです。

値をvm.extfrag_threshold500から100に変更すると、高次の割り当てを優先してメモリを圧縮する可能性が高くなります。ただし、これまでこの値を変更したことはありません/sys/kernel/debug/extfrag/extfrag_index。これは、で使用可能なフラグメンテーションインデックスによって異なります。現時点では、これ以上のものを提供するために必要な新しいカーネルを備えたボックスはありません。

または、何らかのcronジョブ(これは恐ろしく、恐ろしくugい)を実行して、に書き込むことでメモリを手動で圧縮することもできます/proc/sys/vm/compact_memory

しかし、正直なところ、この問題を回避するためにシステムを調整する方法は実際にはないと思います-メモリアロケータの性質がこのように機能するのです。使用するプラットフォームのアーキテクチャを変更することは、おそらく唯一の根本的に解決可能なソリューションです。


現時点では64ビットには不可能です。エラーが発生しないようにシステムを調整する必要があります。
シークエスト

4
これは素晴らしい答えです。
賛成票

こんにちはMlfe、素晴らしい答え。あなたの投稿のこの部分に興味があります。「カーネルは、総空き回線からすべての低位からメモリを効率的に減算し、残っているものに対して最小透かしチェックを実行します。」-私が経験できる関連ソースコードはありますか?なぜなら、私は多くのOOMの問題を扱ってきましたが、ソースでこのロジックを見たことがないからです。おそらく、私は逃した。とにかくどこを見ていますか?oom_kill.c?または他に何か?
ソハムチャクラボルティ

2
コードは、MM / page_alloc.cであり、機能__zone_watermark_okで行わ
マシューイフェ

@SohamChakrabortyこのようなものに興味があるなら、ここにあるように、提供されたOOM-killer出力のスタックトレースに従うことで、カーネルでOOMの原因を理解できることも指摘しておく必要があります。
マシューイフェ

5

最初は、64ビットオペレーティングシステムを使用する必要があります。ここで32ビットのままにする正当な理由はありますか?

システムを詳しく見ることなくこの問題を診断することは難しく、できれば失敗する頃なので、私の(クイック)投稿は多かれ少なかれ32ビットシステムのメモリ問題を対象としています。64ビットにすることでこれがすべてなくなると言いましたか?

あなたの問題は3つあります。

まず、PAEカーネルであっても、プロセスごとのアドレス空間は4GiB [1]に制限されています。これは、squidインスタンスがプロセスごとに4GiBを超えるRAMを消費できないことを意味します。私はsquidにそれほど詳しくはありませんが、これがメインのプロキシサーバーである場合は、とにかく十分ではないかもしれません。

次に、膨大な量のRAMを搭載した32ビットシステムでは、ZONE_HIGHMEMでメモリを使用するために必要なデータ構造を格納するために、「ZONE_NORMAL」と呼ばれるものの多くのメモリが使用されます。これらのデータ構造をZONE_HIGHMEM自体に移動することはできません。これは、カーネルが独自の目的で使用するメモリが常にZONE_NORMAL(つまり、最初の1GiB-ish)にある必要があるためです。カーネルがZONE_HIGHMEMを管理するためにZONE_NORMALからより多くのメモリを必要とするため、ZONE_HIGHMEMにあるメモリ(多くの場合)が多いほど、これは問題になります。ZONE_NORMALの空きメモリ量が枯渇すると、ZONE_NORMALが32ビットシステムで多くの処理が行われる場所になるため、システムが一部のタスクで失敗する可能性があります。すべてのカーネル関連のメモリ操作、たとえば;)

3番目に、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

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

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


1
メモリは通常のゾーン(gfp_maskを参照)から割り当てられていますが、通常のゾーンにはこの割り当てにコミットするのに十分な空きメモリがあります。これについては実際の説明はありますが、投稿をかなり長く編集する必要があります。
マシューイフェ

4

@MIfeはすでにカーネルのメモリ割り当ての処理方法に関する優れた記事を提供しており、64ビットOSへの切り替えや/proc/sys/vm/compact_memoryin による手動メモリ圧縮などの厄介なハックなどの適切なソリューションも提供していますcron

私の2セントはあなたを助けるかもしれない別の回避策になるでしょう:
私はあなたがtcp_tso_segmentあなたのカーネルバックトレースにいることに気づきました:

# ethtool -K ethX tso off gso off lro off

mmより低い次数を使用するように強制することにより、圧力を軽減できます。

PS。すべてのオフロードのリストは、次の方法で取得できます# ethtool -k ethX


2
これは素晴らしい提案です。あなたに賛成です。
マシューイフェ

この情報は非常に良い指針です。TSOの効果も調べます。
シークエスト14年

3

パニックは、sysctl "vm.panic_on_oom = 1"が設定されているためです。システムを再起動すると、システムは正常な状態に戻ります。これはsysctl.confで変更できます。

一番上に、squidがoom killerを呼び出したところがあります。squidの構成とその最大メモリ使用量を確認する(または64ビットOSに移行する)こともできます。

/ proc / meminfoは使用中の高メモリゾーンを示しているため、36GBメモリで32ビットカーネルを実行しています。また、通常のゾーンでは、Squidのメモリの需要を満たすために、カーネルが982ページをスキャンしたが成功しなかったことがわかります。

pages_scanned:982 all_unreclaimable? yes
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.