Ситуація в Linux

У мене ситуація безперервної роботи та паніки невирішена. Я не впевнений, що система заповнює весь баран (36 Гб). Чому ця система викликала цю ситуацію? Я підозрюю, що це стосується зони lowmem в 32-бітних системах Linux. Як я можу проаналізувати журнали з паніки ядра та зловмисників?

З повагою,

Ядро 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-бітний O / S (це 32-бітний), оскільки компонування зон робиться по-іншому.

Гаразд, тут я спробую відповісти, чому ви відчули тут ОМВ. Тут грає ряд факторів.

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

Якщо ви подивитесь на саму УОМ, то, очевидно, є багато вільної пам'яті, але вбивця OOM викликалася? Чому?

Розмір замовлення запиту та те, як ядро ​​поводиться з певними розмірами замовлення

Ядро виділяє пам'ять на замовлення. "Замовлення" - це область постійної оперативної пам’яті, яку необхідно задовольнити для прохання працювати. Замовлення упорядковуються на порядки (таким чином, порядок імен) за допомогою алгоритму 2^(ORDER + 12). Отже, порядок 0 - 4096, порядок 1 - 8192, порядок 2 - 16384 і так далі.

Ядро має жорстке кодове значення того, що вважається "високим порядком" (> PAGE_ALLOC_COSTLY_ORDER). Це порядок 4 і вище (64 кб або вище - це високе замовлення).

Високі замовлення виконуються за розміщення сторінок інакше, ніж низькі. Виділення високого замовлення, якщо не вдасться захопити пам'ять, на сучасних ядрах буде.

• Спробуйте запустити оперативну пам'ять ущільнення для дефрагментації пам'яті.
• Ніколи не дзвоніть вбивцю OOM, щоб задовольнити запит.

Тут розміщено ваш розмір замовлення

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

Замовлення 3 є найвищим із запитів низького замовлення і (як бачите) викликає вбивцю OOM, намагаючись його задовольнити.

Зауважте, що більшість виділень простору користувачів не використовують запити високого замовлення. Зазвичай це ядро, яке потребує суміжних областей пам'яті. Виняток з цього може бути, коли в просторі користувачів використовуються величезні сторінки, але це не так.

У вашому випадку ядро ​​для виклику порядку 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-бітовій платформі. Також для 64-бітових систем Normal відображається до 4 Гб і більше, тоді як для 32-бітових це відображає до 896 Мбіт (хоча у вашому випадку ядро ​​повідомляє лише про меншу частину, ніж ця: - managed:587540kB.)

Можна сказати, звідки взялося це виділення, переглянувши перший рядок, і gfp_mask=0x42d0розповідає про тип виділення. Останній байт (0) говорить нам, що це виділення з нормальної зони. У GFP значення розташовані в включають / Linux / gfp.h .

Водяні знаки, які використовує ця зона.

Коли пам’яті мало, дії щодо її відшкодування визначаються водяним знаком. Вони показують тут: min:3044kB low:3804kB high:4564kB. Якщо вільна пам’ять досягне «низького», заміни будуть відбуватися, поки ми не перейдемо «високий» поріг. Якщо пам'ять досягає «хв», нам потрібно вбити речі, щоб звільнити пам’ять через убивцю OOM.

Фрагментація в зоні.

Для того, щоб побачити, чи можна задовольнити запит на певний порядок пам’яті, ядро ​​обліковує кількість вільних сторінок і доступних для кожного замовлення. Це читається в /proc/buddyinfo. Звіти про вбивство OOM додатково виплювали знайомих також, як тут видно:

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

Для задоволення розподілу пам’яті має бути вільна пам'ять у розмірі замовленого замовлення або більш високому розміщенні. Наявність безлічі вільних даних у низьких замовленнях та жодних у вищих порядках означає, що ваша пам’ять роздроблена. Якщо ви отримаєте дуже високий розмір замовлення, можливо, навіть (з великою кількістю вільної пам’яті) його не буде задоволено через відсутність сторінок високого замовлення. Ядро може дефрагментувати пам'ять (це називається ущільненням пам'яті), переміщуючи безліч сторінок низького порядку, щоб вони не залишали прогалин у адресному просторі оперативної пам’яті.

ОМ-убивцю викликали? Чому?

Отже, якщо ми врахуємо ці речі, ми можемо сказати наступне;

• Повторне виділення 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-бітного змінює розділ вашої зони таким чином, що "Нормальний" становить від 4 ГБ до 36 ГБ, тому ви не будете в результаті "дефолтувати" розподіл пам'яті в зону, яка може настільки сильно роздроблена. Справа не в тому, що у вас є більш адресна пам'ять, яка виправляє цю проблему (адже ви вже використовуєте PAE), лише те, що обрана вами зона має більше адресної пам'яті.

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

Якщо ви зміните значення vm.extfrag_thresholdвід 500 до 100, його більше шансів ущільнити пам'ять, намагаючись вшанувати розподіл високого порядку. Хоча я ніколи раніше не псувався з цим значенням - це також залежатиме від того, який ваш індекс фрагментації доступний /sys/kernel/debug/extfrag/extfrag_index. На даний момент я не маю коробки з новим достатньою кількістю ядра, щоб побачити, що показує, щоб запропонувати більше, ніж це.

Крім того, ви можете запустити якусь роботу з кроном (це жахливо, жахливо), щоб вручну компакт-пам'ять самостійно записуючись /proc/sys/vm/compact_memory.

Якщо чесно кажучи, я не думаю, що дійсно існує спосіб налаштувати систему, щоб уникнути цієї проблеми - її природа розподільника пам'яті працює таким чином. Зміна архітектури використовуваної платформи - це, мабуть, єдине принципово вирішене рішення.

Почнемо з самого початку: вам дійсно слід використовувати 64-бітну операційну систему. Чи є у вас вагомий привід залишитися в 32-бітному місці?

Важко діагностувати цю проблему, не придивляючись до системи більш уважно, бажано в той час, коли вона виходить з ладу, тому моя (швидка) посада більш-менш загально спрямована на проблеми з пам'яттю в 32-бітних системах. Чи згадував я, що 64-розрядний змусить це все пройти?

У вас проблема триразова.

Перш за все, навіть на ядрі PAE, адресний простір за кожний процес обмежений 4GiB [1]. Це означає, що ваш екземпляр кальмарів ніколи не зможе з'їсти більше 4 Гбіт оперативної пам’яті за процес. Я не такий знайомий з кальмарами, але якщо це ваш основний проксі-сервер, цього все одно може бути недостатньо.

По-друге, у 32-бітовій системі з великою кількістю оперативної пам’яті багато пам'яті в тому, що називається «ZONE_NORMAL» використовується для зберігання структур даних, необхідних для використання пам’яті в ZONE_HIGHMEM. Ці структури даних не можуть бути переміщені в ZONE_HIGHMEM самі, тому що пам'ять, яку ядро ​​використовує для власних цілей, завжди має бути в ZONE_NORMAL (тобто в першому 1GiB-ish). Чим більше пам'яті у вас у 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], щоб побачити, чи можете ви сказати, що вбивця може залишити ваші важливі процеси в спокої. Це не вирішить усе (якщо взагалі щось є), але, можливо, варто спробувати.

[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_A_the_Archheh_heer_Archhuh

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

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

@MIfe вже забезпечив відмінні підправити про те , як розподіл пам'яті в ядрі обробляється , а також при умови , вам правильним рішенням , як перехід на 64-бітну ОС і противний хак , як ручне ущільнення пам'яті через /proc/sys/vm/compact_memoryв 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.

Прямо вгорі ми читаємо кальмарів, які викликали убивцю. Ви можете перевірити конфігурацію кальмарів та максимальне використання пам'яті (або просто перейти на 64-бітну ОС).

/ proc / meminfo показує високу зону пам’яті, що використовується, тому ви використовуєте 32-бітове ядро ​​з 36 Гб пам’яті. Ви також можете бачити, що в звичайній зоні, щоб задовольнити попит кальмарів на пам'ять, ядро ​​без успіху сканувало 982 сторінки:

pages_scanned:982 all_unreclaimable? yes