Tenho uma situação de pânico e pânico contínua não resolvida. Não tenho certeza se o sistema preenche toda a memória RAM (36GB). Por que esse sistema desencadeou essa situação desagradável? Eu suspeito que isso esteja relacionado à zona lowmem em sistemas linux de 32 bits. Como posso analisar os logs do kernel panic e oom-killer?
Cumprimentos,
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]
e
# 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
e
# 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
linux
kernel-panic
oom
oom-killer
seaquest
fonte
fonte
Respostas:
Uma abordagem 'marreta' seria atualizar para um O / S de 64 bits (este é 32 bits) porque o layout das zonas é feito de maneira diferente.
OK, então aqui tentarei responder por que você sofreu um OOM aqui. Há vários fatores em jogo aqui.
Se você observar o próprio OOM, há claramente muita memória livre disponível, mas o OOM-killer foi invocado? Por quê?
O tamanho do pedido da solicitação e como o kernel trata certos tamanhos de pedido
O kernel aloca memória por ordem. Um 'pedido' é uma região de RAM contígua que deve ser atendida para que a solicitação funcione. As ordens são organizadas por ordens de magnitude (portanto, a ordem dos nomes) usando o algoritmo
2^(ORDER + 12). Portanto, o pedido 0 é 4096, o pedido 1 é 8192, o pedido 2 é 16384 e assim por diante.O kernel possui um valor codificado do que é considerado uma 'alta ordem' (>
PAGE_ALLOC_COSTLY_ORDER). Esta é a ordem 4 ou superior (64kb ou superior é uma ordem alta).Pedidos altos são satisfeitos para alocações de páginas de maneira diferente dos pedidos baixos. Uma alocação de ordem alta, se não conseguir recuperar a memória, nos kernels modernos.
O tamanho do seu pedido está listado aqui
A ordem 3 é a mais alta das solicitações de baixa ordem e (como você vê) chama o OOM-killer na tentativa de satisfazê-la.
Observe que a maioria das alocações de espaço do usuário não usa solicitações de alta ordem. Normalmente, é o kernel que requer regiões contíguas de memória. Uma exceção a isso pode ser quando o espaço do usuário estiver usando páginas enormes - mas esse não é o caso aqui.
No seu caso, a alocação de ordem 3 é chamada pelo kernel que deseja enfileirar um pacote na pilha de rede - exigindo uma alocação de 32kb para fazer isso.
A zona que está sendo selecionada.
O kernel divide suas regiões de memória em zonas. Esse detalhamento é feito porque em x86 determinadas regiões da memória são endereçáveis apenas por determinado hardware. O hardware mais antigo pode apenas endereçar a memória na zona 'DMA', por exemplo. Quando queremos alocar alguma memória, primeiro uma zona é escolhida e apenas a memória livre dessa zona é contabilizada ao tomar uma decisão de alocação.
Embora eu não esteja totalmente familiarizado com o algoritmo de seleção de zona, o caso de uso típico é nunca alocar do DMA, mas geralmente selecionar a zona endereçável mais baixa que possa atender à solicitação.
Muitas informações da zona são cuspidas durante o OOM, que também podem ser obtidas
/proc/zoneinfo.As zonas que você possui, DMA, Normal e HighMem indicam uma plataforma de 32 bits, porque a zona HighMem não existe em 64 bits. Também em sistemas de 64 bits, o Normal é mapeado para 4 GB e mais além, enquanto em 32 bits ele mapeia até 896 Mb (embora, no seu caso, o kernel reporte apenas o gerenciamento de uma porção menor que esta: -
managed:587540kB.)É possível dizer de onde veio essa alocação, olhando para a primeira linha novamente,
gfp_mask=0x42d0nos diz que tipo de alocação foi feita. O último byte (0) nos diz que essa é uma alocação da zona normal. Os significados GFP estão localizados em include / linux / gfp.h .As marcas d'água que esta zona usa.
Quando a memória está baixa, as ações para recuperá-la são especificadas pela marca d'água. Eles aparecem aqui:
min:3044kB low:3804kB high:4564kB. Se a memória livre atingir 'baixo', a troca ocorrerá até ultrapassarmos o limite 'alto'. Se a memória atingir 'min', precisamos matar coisas para liberar memória através do OOM-killer.Fragmentação na zona.
Para verificar se uma solicitação de uma ordem específica de memória pode ser atendida, o kernel responde por quantas páginas gratuitas e disponíveis para cada ordem. Isso é legível em
/proc/buddyinfo. Os relatórios do OOM-killer também cospem o buddyinfo também, como visto aqui:Para que uma alocação de memória seja satisfeita, deve haver memória livre disponível no tamanho do pedido solicitado ou uma alocação mais alta. Ter muitos e muitos dados livres nas ordens baixas e nenhum nas ordens mais altas significa que sua memória está fragmentada. Se você receber uma alocação de pedidos muito alta, é possível (mesmo com muita memória livre) que ela não seja satisfeita porque não há páginas de pedidos disponíveis. O kernel pode desfragmentar a memória (isso é chamado de compactação de memória) movendo muitas páginas de ordem baixa, para que não deixem lacunas no espaço de memória endereçável.
OOM-killer foi invocado? Por quê?
Portanto, se levarmos essas coisas em consideração, podemos dizer o seguinte;
13*32kB (MR) 1*128kB (R) 1*256kB (R)Então, se não foi memória livre, outras ordens poderia satisfazer o pedido. o que aconteceu?
Bem, há mais na alocação de um pedido do que apenas verificar a quantidade de memória livre disponível para esse pedido ou superior. O kernel subtrai efetivamente a memória de todas as ordens inferiores da linha livre total e, em seguida, executa a verificação mínima da marca d'água no que resta.
O que acontece no seu caso é verificar nossa memória livre para essa zona que devemos fazer.
Essa quantidade de memória livre é comparada com a
minmarca d'água, que é 3044. Portanto, tecnicamente falando - você não tem memória livre para fazer a alocação solicitada. E é por isso que você invocou o OOM-killer.Fixação
Existem duas correções. A atualização para 64 bits altera sua partição de zona, de modo que 'Normal' é de 4 GB a 36 GB; portanto, você não 'padronizará' sua alocação de memória para uma zona que pode ficar tão fragmentada. Não é que você tenha mais memória endereçável que soluciona esse problema (porque você já está usando o PAE), apenas que a zona selecionada tem mais memória endereçável.
A segunda maneira (que eu nunca testei) é tentar fazer o kernel compactar mais agressivamente sua memória.
Se você alterar o valor de
vm.extfrag_threshold500 para 100, é mais provável compactar a memória na tentativa de honrar uma alocação de ordem superior. Embora eu nunca tenha mexido com esse valor antes - ele também dependerá de qual é o seu índice de fragmentação disponível/sys/kernel/debug/extfrag/extfrag_index. No momento, não tenho uma caixa com um kernel novo o suficiente para ver o que isso mostra para oferecer mais do que isso.Como alternativa, você pode executar algum tipo de tarefa cron (isso é horrível, horrivelmente feio) para compactar manualmente a memória, escrevendo-a
/proc/sys/vm/compact_memory.Honestamente, acho que não há realmente uma maneira de ajustar o sistema para evitar esse problema - é a natureza do alocador de memória funcionar dessa maneira. Alterar a arquitetura da plataforma que você usa é provavelmente a única solução fundamentalmente resolvível.
fonte
Desde o início: você realmente deve optar por um sistema operacional de 64 bits. Você tem um bom motivo para ficar em 32 bits aqui?
É difícil diagnosticar esse problema sem dar uma olhada mais atenta no sistema, de preferência no momento em que ele falha, portanto minha postagem (rápida) é mais ou menos genericamente voltada para problemas de memória em sistemas de 32 bits. Eu mencionei que ir de 64 bits faria isso tudo desaparecer?
Seu problema é triplo.
Antes de tudo, mesmo em um kernel PAE, o espaço de endereço por processo é limitado a 4GiB [1]. Isso significa que sua instância do squid nunca poderá consumir mais de 4GiB de RAM por processo. Eu não estou tão familiarizado com o squid, mas se este é o seu servidor proxy principal, isso pode não ser o suficiente.
Segundo, em um sistema de 32 bits com grandes quantidades de RAM, muita memória no que é chamado 'ZONE_NORMAL' é usada para armazenar estruturas de dados necessárias para usar a memória no ZONE_HIGHMEM. Essa estrutura de dados não pode ser movida para o próprio ZONE_HIGHMEM, porque a memória que o kernel usa para seus próprios fins deve sempre estar em ZONE_NORMAL (ou seja, no primeiro 1GiB-ish). Quanto mais memória você tiver no ZONE_HIGHMEM (muito, no seu caso), mais isso se tornará um problema, pois o kernel precisará de mais e mais memória do ZONE_NORMAL para gerenciar o ZONE_HIGHMEM. À medida que a quantidade de memória livre em ZONE_NORMAL seca, seu sistema pode falhar em algumas tarefas, porque ZONE_NORMAL é onde muitas coisas acontecem em um sistema de 32 bits. Todas as operações de memória relacionadas ao kernel, por exemplo;)
Terceiro, mesmo que exista alguma memória em ZONE_NORMAL (não analisei seus logs em detalhes), algumas operações de memória exigirão memória não fragmentada. Por exemplo, se toda a sua memória estiver fragmentada em pedaços realmente pequenos, algumas operações que precisam mais do que isso falharão. [3] Uma breve olhada nos seus logs mostra uma quantidade bastante significativa de fragmentação em ZONE_DMA e ZONE_NORMAL.
Edit: A resposta de Mlfe acima tem uma excelente explicação de como isso funciona em detalhes.
Novamente: em um sistema de 64 bits, toda a memória está em ZONE_NORMAL. Não há zona HIGHMEM em sistemas de 64 bits. Problema resolvido.
Edit: Você pode dar uma olhada aqui [4] para ver se você pode dizer ao oom-killer para deixar seus processos importantes em paz. Isso não resolverá tudo (se é que existe alguma coisa), mas pode valer a pena tentar.
[1] http://en.wikipedia.org/wiki/Physical_address_extension#Design
[2] http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html e 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_hhtemml.html
[3] http://bl0rg.krunch.be/oom-frag.html
[4] http://lwn.net/Articles/317814/
fonte
O @MIfe já forneceu excelentes descrições sobre como as alocações de memória no kernel são tratadas e também forneceu uma solução adequada, como alternar para o SO de 64 bits, e hackers desagradáveis, como compactação manual de memória via
/proc/sys/vm/compact_memoryincron.Meus 2 centavos seriam outra solução alternativa que pode ajudá-lo:
notei que você tem
tcp_tso_segmentno backtrace do kernel, assim:pode diminuir a pressão
mm, forçando-o a usar pedidos inferiores.PS . lista de todas as descargas pode ser obtida via
# ethtool -k ethXfonte
O pânico ocorre porque o sysctl "vm.panic_on_oom = 1" está definido - a idéia é que a reinicialização do sistema o retorne a um estado sadio. Você pode mudar isso no sysctl.conf.
Bem no topo, lemos lulas invocadas pelo assassino. Você pode verificar sua configuração do squid e seu uso máximo de memória (ou apenas mudar para um sistema operacional de 64 bits).
/ proc / meminfo mostra uma zona de memória alta em uso, então você está executando um kernel de 32 bits com 36 GB de memória. Você também pode ver que, na zona normal, para atender à demanda de memória do squid, o kernel digitalizou 982 páginas sem sucesso:
fonte