Tình hình oom Linux

Tôi có tình trạng oom & hoảng loạn liên tục chưa được giải quyết. Tôi không chắc hệ thống sẽ lấp đầy tất cả ram (36GB). Tại sao hệ thống này kích hoạt tình huống oom này? Tôi nghi ngờ nó có liên quan đến vùng lowmem trong các hệ thống linux 32 bit. Làm thế nào tôi có thể phân tích các bản ghi từ kernel hoảng loạn và oom-killer?

Trân trọng,

Hạt nhân 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]

và

# 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

hệ thống:

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

và

# 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

Tuy nhiên, cách tiếp cận 'búa tạ' sẽ là nâng cấp lên O / S 64 bit (đây là 32 bit) vì cách bố trí các vùng được thực hiện khác nhau.

OK, vì vậy ở đây tôi sẽ cố gắng trả lời tại sao bạn đã trải qua một OOM ở đây. Có một số yếu tố chơi ở đây.

• Kích thước thứ tự của yêu cầu và cách xử lý kernel kích thước đơn đặt hàng nhất định.
• Vùng được chọn.
• Các watermark khu vực này sử dụng.
• Sự phân mảnh trong khu vực.

Nếu bạn nhìn vào chính OOM, rõ ràng có rất nhiều bộ nhớ trống có sẵn nhưng kẻ giết người OOM đã được viện dẫn? Tại sao?

Kích thước đơn hàng của yêu cầu và cách nhân xử lý các kích thước đơn hàng nhất định

Nhân phân bổ bộ nhớ theo thứ tự. Một 'đơn hàng' là một vùng RAM liền kề phải được thỏa mãn để yêu cầu hoạt động. Các đơn đặt hàng được sắp xếp theo thứ tự độ lớn (do đó là thứ tự tên) bằng thuật toán 2^(ORDER + 12). Vì vậy, thứ tự 0 là 4096, thứ tự 1 là 8192, thứ tự 2 là 16384, v.v.

Hạt nhân có giá trị được mã hóa cứng của những gì được coi là 'thứ tự cao' (> PAGE_ALLOC_COSTLY_ORDER). Đây là đơn hàng 4 trở lên (64kb trở lên là đơn hàng cao).

Đơn đặt hàng cao được thỏa mãn để phân bổ trang khác với đơn đặt hàng thấp. Một sự phân bổ thứ tự cao nếu nó không lấy được bộ nhớ, trên các hạt nhân hiện đại sẽ.

• Cố gắng chạy bộ nhớ thói quen nén để chống phân mảnh bộ nhớ.
• Không bao giờ gọi OOM-killer để đáp ứng yêu cầu.

Kích thước đặt hàng của bạn được liệt kê ở đây

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

Đơn hàng 3 là yêu cầu cao nhất trong số các yêu cầu cấp thấp và (như bạn thấy) gọi OOM-killer trong nỗ lực thỏa mãn nó.

Lưu ý rằng hầu hết phân bổ không gian người dùng không sử dụng các yêu cầu thứ tự cao. Điển hình là hạt nhân yêu cầu các vùng nhớ liền kề. Một ngoại lệ cho điều này có thể là khi không gian người dùng đang sử dụng các vòng đệm - nhưng đó không phải là trường hợp ở đây.

Trong trường hợp của bạn, phân bổ thứ tự 3 được gọi bởi kernel muốn xếp hàng một gói vào ngăn xếp mạng - yêu cầu phân bổ 32kb để làm như vậy.

Vùng được chọn.

Nhân chia vùng nhớ của bạn thành các vùng. Việc băm nhỏ này được thực hiện bởi vì trên x86 một số vùng bộ nhớ nhất định chỉ có thể truy cập được bằng phần cứng nhất định. Phần cứng cũ hơn chỉ có thể giải quyết bộ nhớ trong vùng 'DMA'. Khi chúng ta muốn phân bổ một số bộ nhớ, đầu tiên một vùng được chọn và chỉ có bộ nhớ trống từ vùng này được tính khi đưa ra quyết định phân bổ.

Mặc dù tôi không hoàn toàn hiểu biết về thuật toán chọn vùng, trường hợp sử dụng thông thường không bao giờ được phân bổ từ DMA, mà thường chọn vùng có địa chỉ thấp nhất có thể đáp ứng yêu cầu.

Rất nhiều thông tin khu vực được đưa ra trong OOM cũng có thể được lượm lặt từ đó /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

Các vùng bạn có, DMA, Bình thường và HighMem chỉ ra nền tảng 32 bit, vì vùng HighMem không tồn tại trên 64 bit. Ngoài ra, trên các hệ thống 64 bit, Bình thường được ánh xạ tới 4GB và hơn thế nữa, trên 32 bit, nó ánh xạ lên tới 896Mb (mặc dù, trong trường hợp của bạn, nhân báo cáo chỉ quản lý một phần nhỏ hơn mức này: - managed:587540kB.)

Có thể cho biết phân bổ này đến từ đâu bằng cách nhìn lại dòng đầu tiên, gfp_mask=0x42d0cho chúng tôi biết loại phân bổ nào đã được thực hiện. Byte cuối cùng (0) cho chúng ta biết rằng đây là phân bổ từ vùng bình thường. Nghĩa gfp được đặt tại bao gồm / linux / gfp.h .

Các watermark khu vực này sử dụng.

Khi bộ nhớ thấp, các hành động để lấy lại nó được chỉ định bởi hình mờ. Họ hiện lên ở đây : min:3044kB low:3804kB high:4564kB. Nếu bộ nhớ trống đạt 'thấp', thì việc hoán đổi sẽ xảy ra cho đến khi chúng ta vượt qua ngưỡng 'cao'. Nếu bộ nhớ đạt đến 'phút', chúng ta cần tiêu diệt các thứ để giải phóng bộ nhớ thông qua kẻ giết người OOM.

Sự phân mảnh trong khu vực.

Để xem liệu một yêu cầu cho một thứ tự bộ nhớ cụ thể có thể được thỏa mãn hay không, kernel chiếm bao nhiêu trang miễn phí và có sẵn của mỗi đơn hàng. Điều này có thể đọc được trong /proc/buddyinfo. Báo cáo kẻ giết người OOM cũng nhổ thêm bạn bè như đã thấy ở đây:

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

Để phân bổ bộ nhớ được thỏa mãn, phải có bộ nhớ trống có sẵn trong kích thước đơn hàng được yêu cầu hoặc phân bổ cao hơn. Có rất nhiều dữ liệu miễn phí trong các đơn hàng thấp và không có dữ liệu nào ở các đơn hàng cao hơn có nghĩa là bộ nhớ của bạn bị phân mảnh. Nếu bạn nhận được phân bổ đơn hàng rất cao thì có thể (thậm chí có nhiều bộ nhớ trống) để nó không được thỏa mãn do không có sẵn các trang có thứ tự cao. Hạt nhân có thể chống phân mảnh bộ nhớ (cái này được gọi là nén bộ nhớ) bằng cách di chuyển nhiều trang có thứ tự thấp xung quanh để chúng không để lại khoảng trống trong không gian ram có thể đánh địa chỉ.

OOM-killer được viện dẫn? Tại sao?

Vì vậy, nếu chúng ta tính đến những điều này, chúng ta có thể nói như sau;

• Một phân bổ liền kề 32kB đã được cố gắng. Từ khu bình thường.
• Có đủ bộ nhớ trống trong vùng được chọn.
• Có sẵn bộ nhớ 3, 5 và 6 13*32kB (MR) 1*128kB (R) 1*256kB (R)

Vì vậy, nếu có là bộ nhớ miễn phí, đơn đặt hàng khác có thể đáp ứng các yêu cầu. Chuyện gì đã xảy ra?

Chà, có nhiều thứ để phân bổ từ một đơn hàng hơn là chỉ kiểm tra lượng bộ nhớ trống có sẵn cho đơn hàng đó hoặc cao hơn. Hạt nhân trừ hiệu quả bộ nhớ từ tất cả các đơn hàng thấp hơn từ tổng dòng miễn phí và sau đó thực hiện kiểm tra hình mờ tối thiểu trên những gì còn lại.

Điều gì xảy ra trong trường hợp của bạn là kiểm tra bộ nhớ trống của chúng tôi cho khu vực đó chúng tôi phải làm.

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

Lượng bộ nhớ trống này được kiểm tra theo minhình mờ, là 3044. Do đó, về mặt kỹ thuật - bạn không còn bộ nhớ trống để thực hiện phân bổ mà bạn yêu cầu. Và đây là lý do tại sao bạn gọi OOM-killer.

Sửa chữa

Có hai cách khắc phục. Nâng cấp lên 64 bit sẽ thay đổi phân vùng vùng của bạn sao cho 'Bình thường' là 4GB lên đến 36GB, do đó bạn sẽ không kết thúc 'mặc định' phân bổ bộ nhớ của mình thành một vùng có thể bị phân mảnh quá nhiều. Không phải là bạn có nhiều bộ nhớ có thể đánh địa chỉ hơn để khắc phục vấn đề này (vì bạn đã sử dụng PAE), chỉ đơn thuần là khu vực bạn chọn có nhiều bộ nhớ có địa chỉ hơn.

Cách thứ hai (mà tôi chưa bao giờ thử nghiệm) là cố gắng lấy kernel để thu gọn bộ nhớ của bạn hơn.

Nếu bạn thay đổi giá trị vm.extfrag_thresholdtừ 500 thành 100, nhiều khả năng nó sẽ thu gọn bộ nhớ trong nỗ lực tôn vinh phân bổ bậc cao. Mặc dù, tôi chưa bao giờ nhầm lẫn với giá trị này trước đây - nó cũng sẽ phụ thuộc vào chỉ số phân mảnh của bạn có sẵn trong đó /sys/kernel/debug/extfrag/extfrag_index. Tôi không có một hộp vào lúc này với một hạt nhân đủ mới để xem những gì hiển thị để cung cấp nhiều hơn thế này.

Ngoài ra, bạn có thể chạy một số loại công việc định kỳ (điều này là khủng khiếp, xấu khủng khiếp) để tự thu gọn bộ nhớ bằng cách viết vào /proc/sys/vm/compact_memory.

Nói một cách trung thực, tôi không nghĩ thực sự có một cách điều chỉnh hệ thống để tránh vấn đề này - đó là bản chất của bộ cấp phát bộ nhớ để hoạt động theo cách này. Thay đổi kiến ​​trúc của nền tảng bạn sử dụng có lẽ là giải pháp cơ bản duy nhất có thể giải quyết được.

Khởi đầu: bạn thực sự nên dùng hệ điều hành 64 bit. Bạn có lý do chính đáng để ở lại 32-bit ở đây không?

Thật khó để chẩn đoán vấn đề này mà không xem xét hệ thống kỹ hơn, tốt nhất là vào khoảng thời gian nó bị lỗi, vì vậy bài đăng (nhanh) của tôi ít nhiều nhắm vào các vấn đề bộ nhớ trên các hệ thống 32 bit. Tôi đã đề cập đến việc đi 64-bit sẽ khiến tất cả biến mất?

Vấn đề của bạn là gấp ba lần.

Trước hết, ngay cả trên nhân PAE, không gian địa chỉ trên mỗi quy trình được giới hạn ở 4GiB [1]. Điều này có nghĩa là cá thể mực của bạn sẽ không bao giờ có thể ăn nhiều hơn 4GiB RAM cho mỗi quy trình. Tôi không quen thuộc với mực, nhưng nếu đây là máy chủ proxy chính của bạn, dù sao thì điều đó có thể không đủ.

Thứ hai, trên hệ thống 32 bit có dung lượng RAM lớn, rất nhiều bộ nhớ trong cái gọi là 'ZONE_NORMAL' được sử dụng để lưu trữ các cấu trúc dữ liệu cần thiết để sử dụng bộ nhớ trong ZONE_HIGHMEM. Các cơ sở hạ tầng này không thể được chuyển vào ZONE_HIGHMEM, vì bộ nhớ mà kernel sử dụng cho mục đích riêng của nó phải luôn ở trong ZONE_NORMAL (tức là trong 1GiB-ish đầu tiên). Bạn càng có nhiều bộ nhớ trong ZONE_HIGHMEM (rất nhiều, trong trường hợp của bạn), điều này càng trở thành vấn đề, bởi vì hạt nhân sau đó cần ngày càng nhiều bộ nhớ từ ZONE_NORMAL để quản lý ZONE_HIGHMEM. Vì dung lượng bộ nhớ trống trong ZONE_NORMAL cạn kiệt, hệ thống của bạn có thể bị lỗi ở một số tác vụ, bởi vì ZONE_NORMAL là nơi xảy ra rất nhiều thứ trên hệ thống 32 bit. Tất cả các hoạt động bộ nhớ liên quan đến kernel, ví dụ;)

Thứ ba, ngay cả khi có một số bộ nhớ còn lại trong ZONE_NORMAL (Tôi chưa xem chi tiết nhật ký của bạn), một số thao tác bộ nhớ sẽ yêu cầu bộ nhớ không phân mảnh. Ví dụ, nếu tất cả bộ nhớ của bạn bị phân mảnh thành các mảnh thực sự nhỏ, một số thao tác cần nhiều hơn thế, sẽ thất bại. [3] Một cái nhìn ngắn gọn về nhật ký của bạn cho thấy số lượng phân mảnh khá đáng kể trong ZONE_DMA và ZONE_NORMAL.

Chỉnh sửa: Câu trả lời của Mlfe ở trên có một lời giải thích tuyệt vời về cách thức hoạt động của chi tiết này.

Một lần nữa: trên hệ thống 64 bit, tất cả bộ nhớ nằm trong ZONE_NORMAL. Không có vùng CAO CẤP trên các hệ thống 64 bit. Vấn đề được giải quyết.

Chỉnh sửa: Bạn có thể xem tại đây [4] để xem liệu bạn có thể nói với kẻ giết người oom để lại các quy trình quan trọng của bạn không. Điều đó sẽ không giải quyết mọi thứ (nếu có bất cứ điều gì), nhưng nó có thể đáng để thử.

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

[2] http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html và https://access.redhat.com/site/documentation/en-US/Red_Hat_ Entryprise_Linux / 5 / html /Tuning__nuning_and_bim__n__b__b__b__b_

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

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

@MIfe đã cung cấp ghi xuất sắc lên về cách phân bổ bộ nhớ trong kernel được xử lý và cũng có thể cung cấp cho bạn giải pháp thích hợp như chuyển sang hệ điều hành 64-bit và khó chịu Hack như thủ công bộ nhớ nén qua /proc/sys/vm/compact_memorytrong cron.

2 xu của tôi sẽ là một cách giải quyết khác có thể giúp bạn:
Tôi đã nhận thấy rằng bạn có tcp_tso_segmenttrong backtrace kernel của mình, vì vậy, thực hiện:

# ethtool -K ethX tso off gso off lro off

có thể giảm áp lực mmbằng cách buộc nó sử dụng các đơn đặt hàng thấp hơn.

PS . danh sách tất cả các giảm tải có thể được lấy thông qua# ethtool -k ethX

Sự hoảng loạn là do sysctl "vm.panic_on_oom = 1" được đặt - ý tưởng là việc khởi động lại hệ thống sẽ đưa nó trở về trạng thái lành mạnh. Bạn có thể thay đổi điều này trong sysctl.conf.

Ngay trên đầu chúng tôi đọc mực gọi kẻ giết người oom. Bạn có thể kiểm tra cấu hình mực của bạn và mức sử dụng bộ nhớ tối đa của nó (hoặc chỉ cần chuyển sang HĐH 64 bit).

/ Proc / meminfo hiển thị vùng bộ nhớ cao đang sử dụng, vì vậy bạn đang chạy kernel 32 bit với bộ nhớ 36GB. Bạn cũng có thể thấy rằng trong vùng bình thường, để đáp ứng nhu cầu bộ nhớ của mực, hạt nhân đã quét 982 trang mà không thành công:

pages_scanned:982 all_unreclaimable? yes