Linux oom ситуация

У меня непрерывная ситуация с унынием и паникой. Я не уверен, что система заполняет все оперативной памяти (36 ГБ). Почему эта система вызвала такую ​​ситуацию? Я подозреваю, что это связано с низкой зоной в 32-битных системах Linux. Как я могу проанализировать логи от паники ядра и 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

Подход «кувалды», однако, заключается в обновлении до 64-битной операционной системы (это 32-битная версия), потому что расположение зон выполняется по-другому.

Итак, здесь я попытаюсь ответить, почему вы испытали OOM здесь. Здесь есть ряд факторов.

• Размер заказа и как ядро ​​обрабатывает определенные размеры заказа.
• Зона выбирается.
• Водяные знаки, используемые в этой зоне.
• Фрагментация в зоне.

Если вы посмотрите на само OOM, есть ли много свободной памяти, но OOM-killer был вызван? Почему?

Размер заказа и как ядро ​​обрабатывает определенные размеры заказа

Ядро распределяет память по порядку. «Порядок» - это область непрерывной оперативной памяти, которая должна быть удовлетворена, чтобы запрос работал. Заказы упорядочены по порядку величины (таким образом, порядок имен) с использованием алгоритма 2^(ORDER + 12). Итак, порядок 0 - 4096, порядок 1 - 8192, порядок 2 - 16384 и так далее.

Ядро имеет жестко закодированное значение того, что считается «высоким порядком» (> PAGE_ALLOC_COSTLY_ORDER). Это порядка 4 и выше (64 КБ или выше - высокий порядок).

Высокие заказы удовлетворяются для распределения страниц в отличие от низких заказов. Распределение высокого порядка, если оно не может захватить память, на современных ядрах будет.

• Попробуйте запустить в памяти процедуру сжатия, чтобы дефрагментировать память.
• Никогда не звоните 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 в попытке удовлетворить его.

Обратите внимание, что большинство распределений пространства пользователя не используют запросы высокого порядка. Обычно это ядро, которое требует смежных областей памяти. Исключением из этого может быть случай, когда пользовательское пространство использует огромные страницы, но здесь это не так.

В вашем случае выделение порядка 3 вызывается ядром, которое хочет поместить пакет в сетевой стек - для этого требуется выделение 32 КБ.

Зона выбирается.

Ядро делит ваши области памяти на зоны. Это разделение сделано, потому что на x86 определенные области памяти могут быть адресованы только определенным оборудованием. Например, старое оборудование может обращаться к памяти только в зоне «DMA». Когда мы хотим выделить некоторую память, сначала выбирается зона, и при принятии решения о выделении учитывается только свободная память из этой зоны.

Хотя я не полностью осведомлен об алгоритме выбора зоны, типичный вариант использования никогда не состоит в выделении из DMA, а в том, чтобы обычно выбирать самую низкую адресуемую зону, которая могла бы удовлетворить запрос.

Во время OOM выкладывается много информации о зоне, которую также можно найти /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

Зоны, которые у вас есть, DMA, Normal и HighMem, обозначают 32-битную платформу, поскольку в 64-битной зоне HighMem не существует. Также в 64-битных системах Normal отображается на 4 ГБ и выше, тогда как на 32-битных картах он отображает до 896 МБ (хотя, в вашем случае, ядро ​​сообщает об управлении только меньшей частью, чем эта: - managed:587540kB.)

Можно узнать, откуда пришло это распределение, посмотрев снова на первую строку, он gfp_mask=0x42d0говорит нам, какой тип распределения был сделан. Последний байт (0) говорит нам, что это выделение из нормальной зоны. В GFP значения расположены в включают / 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

Чтобы выделение памяти было выполнено, должна быть доступная свободная память в запрашиваемом размере заказа или более высоком распределении. Наличие большого и большого количества свободных данных в младших разрядах и ни одного в старших разрядах означает, что ваша память фрагментирована. Если вы получаете очень высокий порядок размещения, возможно (даже с большим количеством свободной памяти) его не удовлетворить из-за отсутствия доступных страниц высокого порядка. Ядро может дефрагментировать память (это называется сжатием памяти), перемещая множество страниц низкого порядка, чтобы они не оставляли пробелов в адресуемом пространстве памяти.

OOM-убийца был вызван? Почему?

Итак, если мы примем эти вещи во внимание, мы можем сказать следующее;

• Была предпринята попытка непрерывного выделения 32 КБ. Из нормальной зоны.
• В выбранной зоне было достаточно свободной памяти.
• Было доступно порядка 3, 5 и 6 памяти 13*32kB (MR) 1*128kB (R) 1*256kB (R)

Таким образом, если бы была свободная память, другие заказы могли бы удовлетворить запрос. что произошло?

Что ж, выделение из заказа - это больше, чем просто проверка объема свободной памяти, доступной для этого заказа или выше. Ядро эффективно вычитает память из всех младших разрядов из общей свободной строки, а затем выполняет проверку минимального водяного знака на оставшемся.

Что происходит в вашем случае, это проверить нашу свободную память для той зоны, которую мы должны сделать.

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

Этот объем свободной памяти minсравнивается с водяным знаком, равным 3044. Таким образом, с технической точки зрения - у вас нет свободной памяти для выполнения запрошенного выделения. И вот почему вы вызвали OOM-убийцу.

Крепежная

Есть два исправления. Обновление до 64 бит изменяет разделение вашей зоны таким образом, что «Normal» составляет 4 ГБ до 36 ГБ, поэтому вы не будете в конечном итоге «по умолчанию» выделять вашу память в зону, которая может быть сильно фрагментирована. Дело не в том, что у вас больше адресуемой памяти, которая решает эту проблему (потому что вы уже используете PAE), просто в выбранной зоне больше адресуемой памяти.

Второй способ (который я никогда не тестировал) - попытаться заставить ядро ​​более агрессивно сжимать вашу память.

Если вы измените значение vm.extfrag_thresholdс 500 на 100, оно с большей вероятностью сократит объем памяти в попытке выполнить распределение высокого порядка. Хотя раньше я никогда не ошибался с этим значением - оно также будет зависеть от того, в каком индексе фрагментации вы находитесь /sys/kernel/debug/extfrag/extfrag_index. На данный момент у меня нет коробки с достаточно новым ядром, чтобы увидеть, что это может предложить больше, чем это.

В качестве альтернативы вы можете запустить какую-то задачу cron (это ужасно, ужасно некрасиво), чтобы вручную сжать память, записав в нее /proc/sys/vm/compact_memory.

Хотя, честно говоря, я не думаю, что на самом деле есть способ настроить систему, чтобы избежать этой проблемы - это характер распределителя памяти, который работает таким образом. Изменение архитектуры используемой вами платформы, вероятно, является единственным принципиально решаемым решением.

С самого начала: вы действительно должны перейти на 64-битную операционную систему. У вас есть веская причина остаться здесь на 32-битной версии?

Трудно диагностировать эту проблему, не присмотревшись к системе более внимательно, желательно во время ее сбоя, поэтому моя (быстрая) статья более или менее в целом направлена ​​на проблемы с памятью в 32-битных системах. Я упоминал, что переход на 64-битную архитектуру заставит все это исчезнуть?

Ваша проблема в три раза.

Во-первых, даже в ядре PAE адресное пространство на процесс ограничено 4 ГБ [1]. Это означает, что ваш экземпляр Squid никогда не сможет использовать более 4 ГБ ОЗУ на процесс. Я не очень знаком с squid, но если это ваш главный прокси-сервер, этого может быть недостаточно.

Во-вторых, в 32-разрядной системе с огромным объемом оперативной памяти большое количество памяти в так называемом ZONE_NORMAL используется для хранения структур данных, необходимых для использования памяти в ZONE_HIGHMEM. Эти структуры данных не могут быть перемещены в ZONE_HIGHMEM сами, потому что память, которую ядро ​​использует для своих собственных целей, всегда должна быть в ZONE_NORMAL (то есть в первом 1GiB-выходе). Чем больше у вас памяти в ZONE_HIGHMEM (много, в вашем случае), тем больше это становится проблемой, потому что ядру требуется все больше и больше памяти от ZONE_NORMAL для управления ZONE_HIGHMEM. Поскольку объем свободной памяти в ZONE_NORMAL иссякает, ваша система может не справиться с некоторыми задачами, потому что ZONE_NORMAL - это то, где много вещей происходит в 32-битной системе. Все операции с памятью, связанные с ядром, например;)

В-третьих, даже если в ZONE_NORMAL осталось немного памяти (я подробно не просматривал ваши журналы), некоторые операции с памятью потребуют нефрагментированной памяти. Например, если вся ваша память фрагментирована на очень маленькие кусочки, некоторые операции, которые требуют большего, завершатся неудачно. [3] Краткий обзор ваших журналов показывает довольно значительную фрагментацию в ZONE_DMA и ZONE_NORMAL.

Изменить: ответ Mlfe выше имеет отличное объяснение того, как это работает в деталях.

Опять же: в 64-битной системе вся память находится в ZONE_NORMAL. В 64-битных системах нет зоны HIGHMEM. Проблема решена.

Изменить: Вы можете посмотреть здесь [4], чтобы увидеть, можете ли вы сказать oom-killer оставить ваши важные процессы в покое. Это не решит все (если вообще что-нибудь), но это может стоить попробовать.

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

[2] http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html и https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html /Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html

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

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

@MIfe уже предоставил отличную информацию о том, как обрабатываются выделения памяти в ядре, а также предоставил вам правильное решение, такое как переключение на 64-битную ОС и неприятный хак, как ручное сжатие памяти через /proc/sys/vm/compact_memoryin cron.

Мои 2 цента были бы другим обходным путем, который может помочь вам:
я заметил, что у вас есть tcp_tso_segmentобратная трассировка в вашем ядре, поэтому делаем:

# ethtool -K ethX tso off gso off lro off

может уменьшить давление mm, заставляя его использовать более низкие порядки.

PS . список всех разгрузок можно получить через# ethtool -k ethX

Паника вызвана тем, что установлен sysctl "vm.panic_on_oom = 1" - идея состоит в том, что перезагрузка системы возвращает его в нормальное состояние. Вы можете изменить это в sysctl.conf.

Прямо наверху мы читаем squid, вызванного oom killer. Вы можете проверить конфигурацию своего squid и его максимальное использование памяти (или просто перейти на 64-битную ОС).

/ proc / meminfo показывает использование зоны высокой памяти, поэтому вы используете 32-битное ядро ​​с 36 ГБ памяти. Вы также можете видеть, что в нормальной зоне, чтобы удовлетворить потребности squid в памяти, ядро ​​безуспешно сканировало 982 страницы:

pages_scanned:982 all_unreclaimable? yes