Sytuacja Linux-a

Mam nierozwiązaną ciągłą sytuację dotyczącą paniki i paniki. Nie jestem pewien, czy system zapełni wszystkie pamięci RAM (36 GB). Dlaczego ten system wywołał tę sytuację? Podejrzewam, że ma to związek ze strefą lowmem w 32-bitowych systemach Linux. Jak mogę analizować logi z paniki jądra i oom-killera?

Z poważaniem,

Jądro 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]

i

# 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

i

# 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

Podejściem „młota kowalskiego” byłoby jednak uaktualnienie do 64-bitowego O / S (jest to 32-bitowy), ponieważ układ stref przebiega inaczej.

OK, więc postaram się tutaj odpowiedzieć, dlaczego doświadczyłeś tutaj OOM. W grę wchodzi wiele czynników.

• Rozmiar zamówienia i sposób, w jaki jądro traktuje określone rozmiary zamówień.
• Wybrana strefa.
• Znaki wodne używane przez tę strefę.
• Fragmentacja w strefie.

Jeśli spojrzysz na samą OOM, jest wyraźnie dużo wolnej pamięci, ale wywołano OOM-killera? Dlaczego?

Rozmiar zamówienia i sposób, w jaki jądro traktuje określone rozmiary zamówień

Jądro przydziela pamięć według kolejności. „Zamówienie” to region ciągłej pamięci RAM, który musi być spełniony, aby żądanie działało. Zamówienia są uporządkowane według rzędów wielkości (a więc kolejności nazw) za pomocą algorytmu 2^(ORDER + 12). Tak więc, rząd 0 to 4096, rząd 1 to 8192, rząd 2 to 16384 i tak dalej.

Jądro ma zakodowaną na stałe wartość, która jest uważana za „wysoki poziom” (> PAGE_ALLOC_COSTLY_ORDER). Jest to kolejność 4 i wyższa (64kb lub wyższa to wysoka kolejność).

Wysokie zamówienia są spełnione dla alokacji stron inaczej niż niskie zamówienia. Przydział wysokiego rzędu, jeśli nie uda mu się pobrać pamięci, w nowoczesnych jądrach zrobi to.

• Spróbuj uruchomić procedurę kompresji pamięci, aby zdefragmentować pamięć.
• Nigdy nie dzwoń do OOM-Killera w celu spełnienia żądania.

Rozmiar twojego zamówienia znajduje się tutaj

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

Kolejność 3 jest najwyższą z żądań niskiego rzędu i (jak widać) wywołuje OOM-killera, próbując ją zaspokoić.

Zauważ, że większość przydziałów przestrzeni użytkownika nie korzysta z żądań wyższego rzędu. Zazwyczaj jest to jądro, które wymaga ciągłych regionów pamięci. Wyjątkiem może być sytuacja, gdy przestrzeń użytkownika korzysta ze stron ukrytych - ale tak nie jest w tym przypadku.

W twoim przypadku przydział rzędu 3 jest wywoływany przez jądro, które chce umieścić pakiet w stosie w kolejce - wymagając przydziału 32kb.

Wybrana strefa.

Jądro dzieli regiony pamięci na strefy. To dzielenie odbywa się, ponieważ na x86 niektóre regiony pamięci są adresowalne tylko przez określony sprzęt. Na przykład starszy sprzęt może być w stanie adresować pamięć tylko w strefie „DMA”. Gdy chcemy przydzielić część pamięci, najpierw wybierana jest strefa i tylko decyzja o przydzieleniu uwzględnia tylko wolną pamięć z tej strefy.

Chociaż nie jestem całkowicie do końca zaznajomiony z algorytmem wyboru strefy, typowym przypadkiem użycia nigdy nie jest alokacja z DMA, ale zwykle wybranie najniższej adresowalnej strefy, która mogłaby spełnić żądanie.

Wiele informacji o strefie jest wyrzucanych podczas OOM, z których można także uzyskać /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

Strefy, które masz, DMA, Normal i HighMem wskazują na platformę 32-bitową, ponieważ strefa HighMem nie istnieje w wersji 64-bitowej. Również w systemach 64-bitowych Normal jest mapowany do 4 GB i więcej, podczas gdy w 32-bitowym mapuje do 896 Mb (chociaż w twoim przypadku jądro zgłasza, że ​​zarządza tylko mniejszą częścią niż ta: - managed:587540kB.)

Można powiedzieć, skąd przyszedł ten przydział, patrząc ponownie na pierwszą linię, gfp_mask=0x42d0mówi nam, jaki rodzaj przydziału został wykonany. Ostatni bajt (0) mówi nam, że jest to przydział ze strefy normalnej. Znaczenia GFP znajdują się w include / linux / gfp.h .

Znaki wodne używane przez tę strefę.

Gdy ilość pamięci jest niska, działania mające na celu jej odzyskanie są określone przez znak wodny. Ukazują się tu: min:3044kB low:3804kB high:4564kB. Jeśli wolna pamięć osiągnie „niski”, wówczas zamiana nastąpi, dopóki nie przekroczymy progu „wysokiego”. Jeśli pamięć osiągnie „min”, musimy zabić rzeczy, aby zwolnić pamięć za pomocą OOM-killera.

Fragmentacja w strefie.

Aby sprawdzić, czy można spełnić żądanie określonej kolejności pamięci, jądro oblicza liczbę wolnych stron i dostępnych dla każdego zamówienia. Można to odczytać w /proc/buddyinfo. Raporty o zabójcach OOM wypluwają także informacje buddyinfo, jak pokazano tutaj:

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

Aby przydział pamięci został spełniony, musi być dostępna wolna pamięć w żądanym rozmiarze zamówienia lub przydział większy. Mnóstwo i dużo wolnych danych w niskich rzędach i brak w wyższych rzędach oznacza, że ​​pamięć jest rozproszona. Jeśli otrzymasz bardzo wysoki przydział zamówień, możliwe jest (nawet przy dużej ilości wolnej pamięci), że nie zostanie on zaspokojony z powodu braku dostępnych stron wysokiego rzędu. Jądro może defragmentować pamięć (nazywa się to kompaktowaniem pamięci), przenosząc wiele stron niskiego rzędu, aby nie pozostawiły luk w adresowalnym obszarze pamięci RAM.

Wywołano zabójcę OOM? Dlaczego?

Jeśli więc weźmiemy pod uwagę te rzeczy, możemy powiedzieć, co następuje;

• Podjęto próbę ciągłego przydziału 32kB. Z normalnej strefy.
• W wybranej strefie była wystarczająca ilość wolnej pamięci.
• Dostępna była pamięć rzędu 3, 5 i 6 13*32kB (MR) 1*128kB (R) 1*256kB (R)

Tak więc, jeśli nie było wolnej pamięci, inne zlecenia mogła spełnić żądania. co się stało?

Przydzielanie z zamówienia to coś więcej niż tylko sprawdzanie ilości wolnej pamięci dostępnej dla tego zamówienia lub wyższej. Jądro skutecznie odejmuje pamięć od wszystkich niższych rzędów od całkowitej wolnej linii, a następnie wykonuje kontrolę minimalnego znaku wodnego na tym, co zostało.

To, co dzieje się w twoim przypadku, to sprawdzenie naszej wolnej pamięci dla strefy, którą musimy zrobić.

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

Ta ilość wolnej pamięci jest minporównywana ze znakiem wodnym, który wynosi 3044. Tak więc technicznie rzecz biorąc - nie masz już wolnej pamięci do wykonania żądanego przydziału. I dlatego przywołałeś OOM-Killera.

Ustalenie

Istnieją dwie poprawki. Uaktualnienie do wersji 64-bitowej powoduje zmianę partycjonowania strefy tak, że „Normalny” wynosi od 4 GB do 36 GB, więc nie skończysz „domyślnym” przydzielaniem pamięci do strefy, która może zostać tak bardzo rozdrobniona. To nie jest tak, że masz więcej adresowalnej pamięci, która rozwiązuje ten problem (ponieważ już korzystasz z PAE), tylko że strefa, którą wybierzesz ma więcej adresowalnej pamięci.

Drugim sposobem (którego nigdy nie testowałem) jest próba zmuszenia jądra do bardziej agresywnego kompaktowania pamięci.

Jeśli zmienisz wartość vm.extfrag_thresholdz 500 na 100, bardziej prawdopodobne jest, że pamięć będzie zwarta, aby uhonorować przydział wysokiego rzędu. Chociaż nigdy wcześniej nie pomieszałem tej wartości - będzie to również zależeć od tego, jaki jest twój indeks fragmentacji, który jest dostępny /sys/kernel/debug/extfrag/extfrag_index. W tej chwili nie mam pudełka z wystarczająco nowym jądrem, aby zobaczyć, co to oferuje, oferując więcej niż to.

Alternatywnie możesz uruchomić jakieś zadanie crona (jest to okropnie, okropnie brzydkie), aby samodzielnie ręcznie skompresować pamięć, pisząc do /proc/sys/vm/compact_memory.

Szczerze mówiąc, nie sądzę, że naprawdę istnieje sposób na dostrojenie systemu, aby uniknąć tego problemu - taka jest natura alokatora pamięci, aby działał w ten sposób. Zmiana architektury używanej platformy jest prawdopodobnie jedynym fundamentalnym rozwiązaniem.

Od samego początku: naprawdę powinieneś wybrać 64-bitowy system operacyjny. Czy masz dobry powód, aby zatrzymać się tutaj w wersji 32-bitowej?

Trudno jest zdiagnozować ten problem bez dokładniejszego przyjrzenia się systemowi, najlepiej mniej więcej w czasie jego awarii, więc mój (szybki) post jest mniej więcej ogólnie związany z problemami z pamięcią w systemach 32-bitowych. Czy wspominałem, że przejście na wersję 64-bitową sprawi, że wszystko zniknie?

Twój problem jest trzykrotnie.

Przede wszystkim, nawet w jądrze PAE, przestrzeń adresowa na proces jest ograniczona do 4GiB [1]. Oznacza to, że instancja kałamarnicy nigdy nie będzie w stanie zjeść więcej niż 4 GB pamięci RAM na proces. Nie jestem zaznajomiony z kałamarnicą, ale jeśli jest to twój główny serwer proxy, to i tak może nie wystarczyć.

Po drugie, w 32-bitowym systemie z ogromną ilością pamięci RAM, dużo pamięci w tak zwanym „ZONE_NORMAL” służy do przechowywania struktur danych potrzebnych do użycia pamięci w ZONE_HIGHMEM. Tej struktury danych nie można przenieść do ZONE_HIGHMEM, ponieważ pamięć używana przez jądro do własnych celów musi zawsze znajdować się w ZONE_NORMAL (tj. W pierwszym 1GiB). Im więcej pamięci masz w ZONE_HIGHMEM (w twoim przypadku dużo), tym bardziej staje się to problemem, ponieważ jądro potrzebuje wtedy coraz więcej pamięci od ZONE_NORMAL do zarządzania ZONE_HIGHMEM. Gdy ilość wolnej pamięci w ZONE_NORMAL wysycha, twój system może zawieść przy niektórych zadaniach, ponieważ ZONE_NORMAL jest miejscem, w którym wiele rzeczy dzieje się w systemie 32-bitowym. Wszystkie operacje pamięci związane z jądrem, na przykład;)

Po trzecie, nawet jeśli w ZONE_NORMAL pozostało trochę pamięci (nie przeglądałem szczegółowo twoich logów), niektóre operacje na pamięci będą wymagały niefragmentowanej pamięci. Na przykład, jeśli cała twoja pamięć jest podzielona na naprawdę małe kawałki, niektóre operacje, które wymagają więcej, zakończą się niepowodzeniem. [3] Krótkie spojrzenie na twoje dzienniki pokazuje dość znaczną fragmentację w ZONE_DMA i ZONE_NORMAL.

Edycja: Powyższa odpowiedź Mlfe zawiera doskonałe wyjaśnienie, w jaki sposób działa to szczegółowo.

Ponownie: w systemie 64-bitowym cała pamięć jest w ZONE_NORMAL. W systemach 64-bitowych nie ma strefy HIGHMEM. Problem rozwiązany.

Edycja: możesz zajrzeć tutaj [4] i sprawdzić, czy możesz powiedzieć oom-killerowi, aby zostawił ważne procesy w spokoju. To nie rozwiąże wszystkiego (jeśli w ogóle cokolwiek), ale warto spróbować.

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

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

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

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

@MIfe już przewidziane doskonałą napisać o tym, jak przydział pamięci w jądrze są obsługiwane , a także ci z właściwego rozwiązania jak przejście na 64-bitowym systemie operacyjnym i bolesnego siekać jak ręczne ubijanie pamięci za pomocą /proc/sys/vm/compact_memoryw cron.

Moje 2 centy byłyby kolejnym obejściem, które może ci pomóc:
Zauważyłem, że masz tcp_tso_segmentw swoim śladzie jądra, więc:

# ethtool -K ethX tso off gso off lro off

może zmniejszyć presję mm, zmuszając go do korzystania z niższych zamówień.

PS . listę wszystkich odciążeń można uzyskać za pośrednictwem# ethtool -k ethX

Panika jest spowodowana ustawieniem sysctl „vm.panic_on_oom = 1” - chodzi o to, że ponowne uruchomienie systemu przywraca go do normalnego stanu. Możesz to zmienić w sysctl.conf.

Na samej górze czytamy, że kałamarnica przywołała zabójcę oom. Możesz sprawdzić konfigurację kałamarnicy i maksymalne wykorzystanie pamięci (lub po prostu przejść do 64-bitowego systemu operacyjnego).

/ proc / meminfo pokazuje używaną strefę wysokiej pamięci, więc używasz 32-bitowego jądra z pamięcią 36 GB. Możesz również zobaczyć, że w normalnej strefie, aby zaspokoić zapotrzebowanie kałamarnicy na pamięć, jądro bez powodzenia zeskanowało 982 strony:

pages_scanned:982 all_unreclaimable? yes