Situasi Linux oom


15

Saya mengalami situasi panik & panik terus-menerus yang belum terselesaikan. Saya tidak yakin sistem mengisi semua ram (36GB). Mengapa sistem ini memicu situasi ini? Saya menduga itu terkait dengan zona lowmem di sistem linux 32 bit. Bagaimana saya bisa menganalisa log dari kernel panik dan oom-killer?

Salam Hormat,

Kernel 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]

dan

# 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

dan

# 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
Hai teman-teman - saya tidak melihat alasan untuk menutup pertanyaan ini. Ini adalah masalah OOM yang menarik.
Nils

1
Saya telah menulis ulang pertanyaan untuk membukanya lagi.
seaquest

Untuk baris berikut "CPU 0: hi: 0, btch: 1 usd: 0", apakah ada yang tahu apa arti "hi", "btch" dan "usd" dan apa unit mereka?
waffleman

Jawaban:


53

Pendekatan 'palu godam' adalah untuk meng-upgrade ke 64bit O / S (ini 32bit) karena tata letak zona dilakukan secara berbeda.

OK, jadi di sini saya akan mencoba menjawab mengapa Anda mengalami OOM di sini. Ada sejumlah faktor yang berperan di sini.

  • Ukuran pesanan dari permintaan dan bagaimana kernel memperlakukan ukuran pesanan tertentu.
  • Zona yang dipilih.
  • Tanda air yang digunakan zona ini.
  • Fragmentasi dalam zona.

Jika Anda melihat OOM itu sendiri, jelas ada banyak memori bebas yang tersedia tetapi pembunuh-OOM dipanggil? Mengapa?


Ukuran pesanan dari permintaan dan bagaimana kernel memperlakukan ukuran pesanan tertentu

Kernel mengalokasikan memori berdasarkan pesanan. 'Pesanan' adalah wilayah RAM yang berdekatan yang harus dipenuhi untuk permintaan untuk bekerja. Pesanan disusun berdasarkan urutan besarnya (dengan demikian urutan nama) menggunakan algoritme 2^(ORDER + 12). Jadi, order 0 adalah 4096, order 1 adalah 8192, order 2 adalah 16384 dan seterusnya.

Kernel memiliki nilai kode keras dari apa yang dianggap sebagai 'pesanan tinggi' (> PAGE_ALLOC_COSTLY_ORDER). Ini adalah pesanan 4 dan lebih tinggi (64kb atau lebih tinggi adalah pesanan tinggi).

Pesanan tinggi puas untuk alokasi halaman berbeda dari pesanan rendah. Alokasi pesanan tinggi jika gagal mengambil memori, pada kernel modern akan.

  • Cobalah untuk menjalankan memori, rutin pemadatan untuk defrag memori.
  • Jangan pernah menelepon pembunuh OOM untuk memenuhi permintaan.

Ukuran pesanan Anda tercantum di sini

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

Pesanan 3 adalah permintaan tingkat rendah tertinggi dan (seperti yang Anda lihat) memanggil pembunuh-OOM dalam upaya untuk memenuhinya.

Perhatikan bahwa sebagian besar alokasi ruang pengguna tidak menggunakan permintaan tingkat tinggi. Biasanya ini adalah kernel yang membutuhkan wilayah memori yang berdekatan. Pengecualian untuk hal ini mungkin ketika userspace menggunakan hugepages - tetapi itu tidak terjadi di sini.

Dalam kasus Anda, alokasi pesanan 3 dipanggil oleh kernel yang ingin mengantri paket ke tumpukan jaringan - membutuhkan alokasi 32kb untuk melakukannya.

Zona yang dipilih.

Kernel membagi wilayah memori Anda menjadi beberapa zona. Pemotongan ini dilakukan karena pada x86 wilayah memori tertentu hanya dapat dialamatkan oleh perangkat keras tertentu. Perangkat keras yang lebih lama mungkin hanya dapat menangani memori di zona 'DMA' misalnya. Saat kami ingin mengalokasikan sebagian memori, pertama-tama zona dipilih dan hanya memori bebas dari zona ini yang diperhitungkan saat membuat keputusan alokasi.

Sementara saya tidak sepenuhnya tahu tentang algoritma pemilihan zona, kasus penggunaan yang umum adalah tidak pernah mengalokasikan dari DMA, tetapi untuk biasanya memilih zona addressable terendah yang dapat memenuhi permintaan.

Banyak informasi zona dimuntahkan selama OOM yang juga dapat diperoleh /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

Zona yang Anda miliki, DMA, Normal dan HighMem menunjukkan platform 32-bit, karena zona HighMem tidak ada pada 64bit. Juga pada sistem 64bit, Normal dipetakan ke 4GB dan seterusnya sedangkan pada 32bit memetakan hingga 896Mb (walaupun, dalam kasus Anda laporan kernel hanya mengelola porsi yang lebih kecil dari ini: - managed:587540kB.)

Mungkin untuk mengetahui dari mana alokasi ini berasal dengan melihat baris pertama lagi, gfp_mask=0x42d0memberi tahu kami jenis alokasi apa yang dilakukan. Byte terakhir (0) memberi tahu kita bahwa ini adalah alokasi dari zona normal. Makna gfp terletak di include / linux / gfp.h .

Tanda air yang digunakan zona ini.

Ketika memori hampir habis, tindakan untuk mengambilnya kembali ditentukan oleh tanda air. Mereka muncul di sini: min:3044kB low:3804kB high:4564kB. Jika memori bebas mencapai 'rendah', maka swapping akan terjadi hingga kami melewati ambang 'tinggi'. Jika memori mencapai 'min', kita perlu membunuh barang untuk membebaskan memori melalui OOM-killer.

Fragmentasi dalam zona.

Untuk melihat apakah permintaan untuk urutan memori tertentu dapat dipenuhi, kernel memperhitungkan berapa banyak halaman gratis dan tersedia untuk setiap pesanan. Ini bisa dibaca di /proc/buddyinfo. Laporan pembunuh OOM juga memuntahkan buddyinfo seperti yang terlihat di sini:

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

Agar alokasi memori dipenuhi, harus ada memori kosong yang tersedia dalam ukuran pesanan yang diminta atau alokasi yang lebih tinggi. Memiliki banyak dan banyak data gratis dalam pesanan rendah dan tidak ada dalam pesanan yang lebih tinggi berarti memori Anda terfragmentasi. Jika Anda mendapatkan alokasi pesanan sangat tinggi, kemungkinannya (bahkan dengan banyak memori bebas) tidak dapat dipenuhi karena tidak ada halaman pesanan tinggi yang tersedia. Kernel dapat mendefrag memori (ini disebut pemadatan memori) dengan memindahkan banyak halaman dengan urutan rendah sehingga tidak meninggalkan celah di ruang ram yang dapat dialamatkan.

Pembunuh-OOM dipanggil? Mengapa?

Jadi, jika kita mempertimbangkan hal-hal ini, kita dapat mengatakan yang berikut;

  • Alokasi bersebelahan 32kB dicoba. Dari zona normal.
  • Ada cukup memori bebas di zona yang dipilih.
  • Ada pesanan 3, 5 dan 6 memori tersedia 13*32kB (MR) 1*128kB (R) 1*256kB (R)

Jadi, jika ada adalah memori bebas, perintah lainnya bisa memenuhi permintaan tersebut. apa yang terjadi?

Nah, ada lebih banyak alokasi dari pesanan daripada hanya memeriksa jumlah memori bebas yang tersedia untuk pesanan itu atau lebih tinggi. Kernel secara efektif mengurangi memori dari semua pesanan yang lebih rendah dari garis bebas total dan kemudian melakukan pemeriksaan tanda air min pada apa yang tersisa.

Apa yang terjadi dalam kasus Anda adalah memeriksa memori bebas kami untuk zona yang harus kami lakukan.

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

Jumlah memori bebas ini diperiksa terhadap mintanda air, yaitu 3044. Dengan demikian, secara teknis - Anda tidak memiliki memori bebas yang tersisa untuk melakukan alokasi yang Anda minta. Dan inilah mengapa Anda memanggil pembunuh-OOM.


Pemasangan

Ada dua perbaikan. Upgrade ke 64bit mengubah partisi zona Anda sehingga 'Normal' adalah 4GB hingga 36GB, sehingga Anda tidak akan 'defaulting' alokasi memori Anda ke dalam zona yang bisa sangat terfragmentasi. Ini bukan berarti Anda memiliki lebih banyak memori yang dapat dialamatkan yang memperbaiki masalah ini (karena Anda sudah menggunakan PAE), hanya bahwa zona yang Anda pilih memiliki lebih banyak memori yang dapat dialamatkan.

Cara kedua (yang belum pernah saya uji) adalah mencoba mendapatkan kernel untuk memadatkan memori Anda secara lebih agresif.

Jika Anda mengubah nilai vm.extfrag_thresholddari 500 menjadi 100, itu lebih cenderung memadatkan memori dalam upaya untuk menghormati alokasi tingkat tinggi. Meskipun, saya tidak pernah mengacaukan nilai ini sebelumnya - itu juga akan tergantung pada apa indeks fragmentasi Anda yang tersedia di /sys/kernel/debug/extfrag/extfrag_index. Saya tidak punya kotak saat ini dengan kernel yang cukup baru untuk melihat apa yang menawarkan lebih dari ini.

Atau Anda dapat menjalankan semacam pekerjaan cron (ini mengerikan, sangat jelek) untuk secara manual memadatkan memori Anda sendiri dengan menuliskannya /proc/sys/vm/compact_memory.

Tapi sejujurnya, saya tidak berpikir benar-benar ada cara untuk memperbaiki sistem untuk menghindari masalah ini - itu adalah sifat dari pengalokasi memori untuk bekerja dengan cara ini. Mengubah arsitektur platform yang Anda gunakan mungkin merupakan satu-satunya solusi yang dapat dipecahkan secara mendasar.


Masuk ke 64 bit tidak mungkin saat ini. Saya harus memperbaiki sistem agar tidak mendapatkan kesalahan.
seaquest

4
Ini jawaban yang luar biasa. Punya upvote :)
wzzrd

Hai Mlfe, jawaban yang bagus. Saya ingin tahu tentang bagian posting Anda ini. "Kernel secara efektif mengurangi memori dari semua pesanan yang lebih rendah dari garis bebas total dan kemudian melakukan pemeriksaan tanda air min pada apa yang tersisa." - Apakah Anda memiliki kode sumber yang relevan yang dapat saya lalui? Karena, yah, saya telah menangani banyak masalah OOM tetapi saya belum melihat sumber logika ini. Mungkin, saya ketinggalan. Di mana Anda melihat? oom_kill.c? Atau sesuatu yang lain?
Soham Chakraborty

2
Kode ini dalam mm / page_alloc.c dan dilakukan dalam fungsi __zone_watermark_ok
Matthew Ife

@SohamChakraborty Jika Anda tertarik dengan hal ini, saya juga harus menunjukkan bahwa Anda dapat mengetahui apa yang menyebabkan OOM di kernel dengan mengikuti jejak stack pada output pembunuh OOM yang disediakan, seperti halnya di sini.
Matthew Ife

5

Off the start: Anda harus benar - benar menggunakan sistem operasi 64-bit. Apakah Anda punya alasan kuat untuk tetap di 32-bit di sini?

Sulit untuk mendiagnosis masalah ini tanpa melihat sistem lebih dekat, lebih disukai sekitar waktu gagal, sehingga posting (cepat) saya secara umum ditujukan untuk masalah memori pada sistem 32-bit. Apakah saya menyebutkan akan 64-bit akan membuat semua ini hilang?

Masalah Anda tiga kali lipat.

Pertama-tama, bahkan pada kernel PAE, ruang alamat per proses dibatasi hingga 4GiB [1]. Ini berarti bahwa instance cumi-cumi Anda tidak akan pernah bisa makan lebih dari 4 Gb RAM per proses. Saya tidak begitu terbiasa dengan squid, tetapi jika ini adalah server proxy utama Anda, itu mungkin tidak cukup.

Kedua, pada sistem 32-bit dengan jumlah RAM yang besar, banyak memori dalam apa yang disebut 'ZONE_NORMAL' digunakan untuk menyimpan struktur data yang diperlukan untuk menggunakan memori di ZONE_HIGHMEM. Datastruktur ini tidak dapat dipindahkan ke ZONE_HIGHMEM sendiri, karena memori yang digunakan kernel untuk keperluannya sendiri harus selalu dalam ZONE_NORMAL (yaitu pada 1GiB-ish pertama). Semakin banyak memori yang Anda miliki di ZONE_HIGHMEM (banyak, dalam kasus Anda), semakin banyak ini menjadi masalah, karena kernel kemudian membutuhkan lebih banyak memori dari ZONE_NORMAL untuk mengelola ZONE_HIGHMEM. Karena jumlah memori bebas di ZONE_NORMAL mengering, sistem Anda mungkin gagal pada beberapa tugas, karena ZONE_NORMAL adalah tempat banyak hal terjadi pada sistem 32-bit. Semua operasi memori terkait kernel, misalnya;)

Ketiga, bahkan jika ada beberapa memori yang tersisa di ZONE_NORMAL (Saya belum memeriksa log Anda secara detail), beberapa operasi memori akan membutuhkan memori yang tidak terfragmentasi. Misalnya, jika semua memori Anda terfragmentasi menjadi bagian-bagian yang sangat kecil, beberapa operasi yang membutuhkan lebih dari itu, akan gagal. [3] Pengamatan singkat pada log Anda menunjukkan jumlah fragmentasi yang cukup signifikan di ZONE_DMA dan ZONE_NORMAL.

Sunting: Jawaban Mlfe di atas memiliki penjelasan yang sangat baik tentang bagaimana ini bekerja secara rinci.

Lagi: pada sistem 64-bit, semua memori ada di ZONE_NORMAL. Tidak ada zona HIGHMEM pada sistem 64-bit. Masalah terpecahkan.

Sunting: Anda bisa melihat di sini [4] untuk melihat apakah Anda dapat memberitahu oom-killer untuk meninggalkan proses penting Anda sendirian. Itu tidak akan menyelesaikan segalanya (jika ada sama sekali), tetapi mungkin patut dicoba.

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

[2] http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html dan 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_Kem _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _.

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

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


1
Memori sedang dialokasikan dari zona normal (lihat gfp_mask), meskipun pada pandangan pertama zona normal memiliki cukup memori bebas untuk melakukan alokasi ini. Saya memang punya penjelasan aktual untuk ini, tetapi itu membutuhkan pengeditan yang cukup panjang untuk posting saya.
Matthew Ife

4

@MIfe sudah menyediakan penulisan yang sangat baik tentang bagaimana alokasi memori dalam kernel ditangani dan juga memberi Anda solusi yang tepat seperti beralih ke OS 64-bit dan hack jahat seperti pemadatan memori manual via /proc/sys/vm/compact_memoryin cron.

2 sen saya akan menjadi solusi lain yang dapat membantu Anda:
Saya perhatikan Anda memiliki tcp_tso_segmentdi backtrace kernel Anda, dengan melakukan hal ini:

# ethtool -K ethX tso off gso off lro off

dapat menurunkan tekanan mmdengan memaksanya untuk menggunakan pesanan yang lebih rendah.

PS . daftar semua offload dapat diperoleh melalui# ethtool -k ethX


2
Ini adalah saran yang brilian. Suara positif bagi Anda.
Matthew Ife

Info ini adalah penunjuk yang sangat bagus. Saya juga akan memeriksa efek tso.
seaquest

3

Kepanikan karena sysctl "vm.panic_on_oom = 1" diset - idenya adalah me-reboot sistem mengembalikannya ke keadaan waras. Anda dapat mengubahnya di sysctl.conf.

Tepat di atas kita membaca cumi dipanggil pembunuh. Anda mungkin memeriksa konfigurasi squid Anda dan penggunaan memori maksimumnya (atau hanya pindah ke OS 64-bit).

/ proc / meminfo menampilkan zona memori tinggi yang digunakan, jadi Anda menjalankan kernel 32-bit dengan memori 36GB. Anda juga dapat melihat bahwa di zona normal, untuk memenuhi permintaan squid untuk memori, kernel memindai 982 halaman tanpa hasil:

pages_scanned:982 all_unreclaimable? yes
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.