Situation de Linux oom

J'ai une situation de panique et de panique continue non résolue. Je ne suis pas sûr que le système remplisse tout le ram (36 Go). Pourquoi ce système a déclenché cette situation oom? Je le soupçonne comme lié à la zone lowmem dans les systèmes Linux 32 bits. Comment puis-je analyser les journaux de panique du noyau et oom-killer?

Meilleures salutations,

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

et

# 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

et

# 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

Une approche 'sledgehammer' serait cependant de passer à un 64 bits O / S (c'est 32 bits) car la disposition des zones se fait différemment.

OK, ici je vais essayer de répondre à la raison pour laquelle vous avez rencontré un MOO ici. Il y a un certain nombre de facteurs en jeu ici.

• La taille de la commande et la façon dont le noyau traite certaines tailles de commande.
• La zone sélectionnée.
• Les filigranes utilisés par cette zone.
• Fragmentation dans la zone.

Si vous regardez le MOO lui-même, il y a clairement beaucoup de mémoire disponible mais OOM-killer a été invoqué? Pourquoi?

La taille de la commande et la façon dont le noyau traite certaines tailles de commande

Le noyau alloue de la mémoire par ordre. Une «commande» est une région de RAM contiguë qui doit être satisfaite pour que la demande fonctionne. Les ordres sont classés par ordre de grandeur (d'où l'ordre du nom) à l'aide de l'algorithme 2^(ORDER + 12). Ainsi, l'ordre 0 est 4096, l'ordre 1 est 8192, l'ordre 2 est 16384 et ainsi de suite.

Le noyau a une valeur codée en dur de ce qui est considéré comme un «ordre élevé» (> PAGE_ALLOC_COSTLY_ORDER). Il s'agit de l'ordre 4 et supérieur (64 Ko ou plus est un ordre élevé).

Les commandes élevées sont satisfaites pour les allocations de pages différemment des commandes faibles. Une allocation d'ordre élevé s'il ne parvient pas à saisir la mémoire, sur les noyaux modernes le fera.

• Essayez d'exécuter en mémoire la routine de compactage pour défragmenter la mémoire.
• N'appelez jamais OOM-killer pour satisfaire la demande.

La taille de votre commande est indiquée ici

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

L'ordre 3 est la plus élevée des demandes de faible niveau et (comme vous le voyez) invoque OOM-killer pour tenter de le satisfaire.

Notez que la plupart des allocations d'espace utilisateur n'utilisent pas de requêtes de niveau élevé. Généralement, c'est le noyau qui nécessite des régions de mémoire contiguës. Une exception à cela peut être lorsque l'espace utilisateur utilise des pages géantes - mais ce n'est pas le cas ici.

Dans votre cas, l'allocation d'ordre 3 est appelée par le noyau qui souhaite mettre en file d'attente un paquet dans la pile réseau - ce qui nécessite une allocation de 32 Ko.

La zone sélectionnée.

Le noyau divise vos régions de mémoire en zones. Ce découpage est effectué car sur x86 certaines régions de mémoire ne sont adressables que par certains matériels. Le matériel plus ancien peut seulement être capable d'adresser la mémoire dans la zone 'DMA' par exemple. Lorsque nous voulons allouer de la mémoire, une zone est d'abord choisie et seule la mémoire libre de cette zone est prise en compte lors d'une décision d'allocation.

Bien que je ne sois pas complètement au courant de l'algorithme de sélection de zone, le cas d'utilisation typique n'est jamais d'allouer à partir de DMA, mais de sélectionner généralement la zone adressable la plus basse qui pourrait satisfaire la demande.

De nombreuses informations de zone sont crachées pendant le MOO, qui peuvent également être glanées /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

Les zones que vous avez, DMA, Normal et HighMem indiquent une plate-forme 32 bits, car la zone HighMem est inexistante sur 64 bits. Également sur les systèmes 64 bits, Normal est mappé à 4 Go et au-delà tandis que sur 32 bits, il correspond à 896 Mo (bien que, dans votre cas, le noyau signale ne gérer qu'une partie plus petite que celle-ci: - managed:587540kB.)

Il est possible de dire d'où vient cette allocation en regardant à nouveau la première ligne, gfp_mask=0x42d0nous dit quel type d'allocation a été fait. Le dernier octet (0) nous indique qu'il s'agit d'une allocation de la zone normale. Les significations de GFP sont situés dans include / linux / gfp.h .

Les filigranes utilisés par cette zone.

Lorsque la mémoire est faible, les actions pour la récupérer sont spécifiées par le filigrane. Ils apparaissent ici: min:3044kB low:3804kB high:4564kB. Si la mémoire libre atteint le niveau «bas», un échange se produira jusqu'à ce que nous dépassions le seuil «haut». Si la mémoire atteint «min», nous devons tuer des choses afin de libérer de la mémoire via le tueur OOM.

Fragmentation dans la zone.

Afin de voir si une demande pour un ordre de mémoire spécifique peut être satisfaite, le noyau représente le nombre de pages libres et disponibles de chaque commande. Ceci est lisible en /proc/buddyinfo. Les rapports OOM-killer crachent également le buddyinfo comme on le voit ici:

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

Pour qu'une allocation de mémoire soit satisfaite, il doit y avoir de la mémoire disponible dans la taille de commande demandée ou une allocation supérieure. Avoir beaucoup, beaucoup de données gratuites dans les commandes faibles et aucune dans les commandes supérieures signifie que votre mémoire est fragmentée. Si vous obtenez une allocation de commande très élevée, il est possible (même avec beaucoup de mémoire libre) qu'elle ne soit pas satisfaite car il n'y a pas de pages de commande élevée disponibles. Le noyau peut défragmenter la mémoire (c'est ce qu'on appelle le compactage de la mémoire) en déplaçant de nombreuses pages de faible poids afin de ne pas laisser d'espace dans l'espace ram adressable.

OOM-killer a été invoqué? Pourquoi?

Donc, si nous tenons compte de ces choses, nous pouvons dire ce qui suit;

• Une allocation contiguë de 32 Ko a été tentée. De la zone normale.
• Il y avait suffisamment de mémoire libre dans la zone sélectionnée.
• Il y avait de l'ordre de 3, 5 et 6 mémoires disponibles 13*32kB (MR) 1*128kB (R) 1*256kB (R)

Ainsi, s'il y avait de la mémoire libre, d'autres commandes pourraient satisfaire la demande. Qu'est-il arrivé?

Eh bien, il y a plus à allouer à partir d'une commande que de simplement vérifier la quantité de mémoire libre disponible pour cette commande ou plus. Le noyau soustrait efficacement la mémoire de tous les ordres inférieurs de la ligne libre totale, puis effectue la vérification du filigrane min sur ce qui reste.

Ce qui se passe dans votre cas, c'est de vérifier notre mémoire libre pour cette zone que nous devons faire.

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

Cette quantité de mémoire libre est vérifiée par rapport au minfiligrane, qui est 3044. Ainsi, techniquement parlant - vous n'avez plus de mémoire libre pour faire l'allocation que vous avez demandée. Et c'est pourquoi vous avez invoqué OOM-killer.

Fixation

Il existe deux correctifs. La mise à niveau vers 64 bits modifie votre partitionnement de zone de sorte que `` Normal '' est de 4 Go à 36 Go, vous ne finirez donc pas par `` par défaut '' votre allocation de mémoire dans une zone qui peut être si fortement fragmentée. Ce n'est pas que vous avez plus de mémoire adressable qui résout ce problème (parce que vous utilisez déjà PAE), mais simplement que la zone que vous sélectionnez a plus de mémoire adressable.

La deuxième façon (que je n'ai jamais testée) est d'essayer d'amener le noyau à compacter plus agressivement votre mémoire.

Si vous modifiez la valeur de vm.extfrag_threshold500 à 100, il est plus probable qu'elle compacte la mémoire dans le but d'honorer une allocation d'ordre élevé. Bien que je n'aie jamais joué avec cette valeur auparavant - cela dépendra également de votre index de fragmentation disponible /sys/kernel/debug/extfrag/extfrag_index. Je n'ai pas de boîte pour le moment avec un noyau suffisamment nouveau pour voir ce que cela montre à offrir de plus que cela.

Alternativement, vous pouvez exécuter une sorte de tâche cron (c'est horriblement, horriblement laid) pour compacter manuellement la mémoire vous-même en écrivant dans /proc/sys/vm/compact_memory.

En toute honnêteté cependant, je ne pense pas qu'il y ait vraiment un moyen de régler le système pour éviter ce problème - c'est la nature de l'allocateur de mémoire pour fonctionner de cette façon. Changer l'architecture de la plateforme que vous utilisez est probablement la seule solution fondamentalement résolvable.

Dès le départ: vous devriez vraiment opter pour un système d'exploitation 64 bits. Avez-vous une bonne raison de rester ici en 32 bits?

Il est difficile de diagnostiquer ce problème sans regarder de plus près le système, de préférence au moment où il échoue, donc mon message (rapide) vise plus ou moins génériquement les problèmes de mémoire sur les systèmes 32 bits. Ai-je mentionné que passer au 64 bits ferait disparaître tout cela?

Votre problème est triple.

Tout d'abord, même sur un noyau PAE, l'espace d'adressage par processus est limité à 4GiB [1]. Cela signifie que votre instance de calmar ne pourra jamais consommer plus de 4 Go de RAM par processus. Je ne suis pas très familier avec Squid, mais si c'est votre serveur proxy principal, cela pourrait ne pas être suffisant de toute façon.

Deuxièmement, sur un système 32 bits avec de grandes quantités de RAM, beaucoup de mémoire dans ce qu'on appelle «ZONE_NORMAL» est utilisée pour stocker les structures de données qui sont nécessaires pour utiliser la mémoire dans ZONE_HIGHMEM. Ces infrastructures de données ne peuvent pas être déplacées dans ZONE_HIGHMEM elles-mêmes, car la mémoire que le noyau utilise à ses propres fins doit toujours être dans ZONE_NORMAL (c'est-à-dire dans le premier 1GiB-ish). Plus vous avez de mémoire dans ZONE_HIGHMEM (beaucoup, dans votre cas), plus cela devient un problème, car le noyau a alors besoin de plus en plus de mémoire de ZONE_NORMAL pour gérer ZONE_HIGHMEM. À mesure que la quantité de mémoire libre dans ZONE_NORMAL s'assèche, votre système peut échouer à certaines tâches, car ZONE_NORMAL est l'endroit où beaucoup de choses se produisent sur un système 32 bits. Toutes les opérations mémoire liées au noyau, par exemple;)

Troisièmement, même s'il reste de la mémoire dans ZONE_NORMAL (je n'ai pas parcouru vos journaux en détail), certaines opérations de mémoire nécessiteront de la mémoire non fragmentée. Par exemple, si toute votre mémoire est fragmentée en très petits morceaux, certaines opérations qui nécessitent plus que cela, échoueront. [3] Un bref examen de vos journaux montre une quantité assez importante de fragmentation dans ZONE_DMA et ZONE_NORMAL.

Edit: La réponse de Mlfe ci-dessus a une excellente explication de la façon dont cela fonctionne en détail.

Encore une fois: sur un système 64 bits, toute la mémoire est dans ZONE_NORMAL. Il n'y a pas de zone HIGHMEM sur les systèmes 64 bits. Problème résolu.

Edit: Vous pouvez jeter un oeil ici [4] pour voir si vous pouvez dire à oom-killer de laisser vos processus importants seuls. Cela ne résoudra pas tout (le cas échéant), mais cela pourrait valoir la peine d'être essayé.

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

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

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

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

@MIfe a déjà fourni une excellente écriture sur la façon dont les allocations de mémoire dans le noyau sont gérées et vous a également fourni une solution appropriée comme le passage à un système d'exploitation 64 bits et un piratage méchant comme le compactage manuel de la mémoire via /proc/sys/vm/compact_memoryin cron.

Mes 2 cents seraient une autre solution de contournement qui pourrait vous aider:
j'ai remarqué que vous avez tcp_tso_segmentdans votre backtrace du noyau, ce faisant:

# ethtool -K ethX tso off gso off lro off

peut diminuer la pression mmen l'obligeant à utiliser des commandes inférieures.

PS . la liste de tous les déchargements peut être obtenue via# ethtool -k ethX

La panique est due au fait que le sysctl "vm.panic_on_oom = 1" est défini - l'idée est que le redémarrage du système le ramène à un état sain. Vous pouvez changer cela dans sysctl.conf.

Tout en haut, nous lisons calmars invoqué oom killer. Vous pouvez vérifier votre configuration Squid et son utilisation maximale de la mémoire (ou simplement passer à un système d'exploitation 64 bits).

/ proc / meminfo affiche une zone de mémoire élevée utilisée, vous exécutez donc un noyau 32 bits avec 36 Go de mémoire. Vous pouvez également voir que dans la zone normale, afin de répondre à la demande de mémoire de Squid, le noyau a numérisé 982 pages sans succès:

pages_scanned:982 all_unreclaimable? yes