สถานการณ์ของ Linux

15

ฉันมีสถานการณ์ที่ไม่แน่นอนอย่างต่อเนื่อง ฉันไม่แน่ใจว่าระบบเติม RAM ทั้งหมด (36GB) ทำไมระบบนี้ทำให้เกิดสถานการณ์แบบนี้? ฉันสงสัยว่ามันเกี่ยวข้องกับโซน lowmem ในระบบลินุกซ์ 32 บิต ฉันจะวิเคราะห์ล็อกจากเคอร์เนล panic และ 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
linux  kernel-panic  oom  oom-killer 
— Seaquest
แหล่งที่มา
6
เฮ้คน - ฉันไม่เห็นเหตุผลที่จะปิดคำถามนี้ นี่เป็นปัญหา OOM ที่น่าสนใจ
— นิลส์
1
ฉันได้ตั้งคำถามใหม่เพื่อเปิดอีกครั้ง
— seaquest
สำหรับบรรทัดต่อไปนี้ "CPU 0: hi: 0, btch: 1 usd: 0" ไม่มีใครรู้ว่า "hi", "btch" และ "usd" หมายถึงอะไรและหน่วยของพวกเขาคืออะไร?
— waffleman

คำตอบ:

53

วิธี 'sledgehammer' แม้ว่าจะเป็นการอัพเกรดเป็น 64 บิต O / S (นี่คือ 32 บิต) เนื่องจากเลย์เอาต์ของโซนต่างกัน

ตกลงดังนั้นที่นี่ฉันจะพยายามที่จะตอบว่าทำไมคุณมีประสบการณ์ OOM ที่นี่ มีหลายปัจจัยที่เล่นอยู่ที่นี่

  • ขนาดการสั่งซื้อของคำขอและวิธีที่เคอร์เนลปฏิบัติต่อขนาดการสั่งซื้อที่แน่นอน
  • โซนที่ถูกเลือก
  • ลายน้ำโซนนี้ใช้
  • การกระจายตัวในโซน

ถ้าคุณดูที่ OOM นั้นจะมีหน่วยความจำว่างให้เลือกมากมาย แต่ OOM-killer ถูกเรียกใช้หรือไม่ ทำไม?

ขนาดการสั่งซื้อของการร้องขอและวิธีที่เคอร์เนลปฏิบัติต่อขนาดการสั่งซื้อที่แน่นอน

เคอร์เนลจัดสรรหน่วยความจำตามลำดับ 'สั่งซื้อ' เป็นพื้นที่ของ RAM ที่ต่อเนื่องกันซึ่งจะต้องมีความพึงพอใจสำหรับการร้องขอให้ทำงาน คำสั่งซื้อจะถูกจัดเรียงโดยคำสั่งของขนาด (ดังนั้นเพื่อชื่อ) 2^(ORDER + 12)โดยใช้อัลกอริทึม ดังนั้นคำสั่ง 0 คือ 4096 คำสั่งที่ 1 คือ 8192 คำสั่งที่ 2 คือ 16384 เป็นต้นไปเรื่อย ๆ

เคอร์เนลมีค่ารหัสตายตัวของสิ่งที่ถือว่าเป็น 'ลำดับสูง' (> PAGE_ALLOC_COSTLY_ORDER) นี่คือคำสั่ง 4 และสูงกว่า (64kb หรือสูงกว่าเป็นคำสั่งที่สูง)

คำสั่งซื้อสูงมีความพึงพอใจสำหรับการจัดสรรหน้าแตกต่างจากคำสั่งซื้อต่ำ การจัดสรรลำดับสูงถ้าไม่สามารถดึงหน่วยความจำได้

  • ลองเรียกใช้หน่วยความจำรูทีนการกระชับเพื่อจัดเรียงหน่วยความจำ
  • อย่าเรียก 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 ในความพยายามที่จะตอบสนอง

โปรดทราบว่าการจัดสรรพื้นที่ผู้ใช้ส่วนใหญ่ไม่ได้ใช้คำขอที่มีลำดับสูง โดยทั่วไปแล้วเคอร์เนลจะต้องใช้พื้นที่หน่วยความจำที่ต่อเนื่องกัน ข้อยกเว้นนี้อาจเกิดขึ้นเมื่อ userspace ใช้ hugepages - แต่นี่ไม่ใช่กรณีที่นี่

ในกรณีของคุณการจัดสรรลำดับ 3 จะถูกเรียกใช้โดยเคอร์เนลที่ต้องการจัดคิวแพ็คเก็ตลงในสแต็กเครือข่ายซึ่งต้องการการจัดสรร 32kb เพื่อดำเนินการดังกล่าว

โซนที่ถูกเลือก

เคอร์เนลแบ่งขอบเขตหน่วยความจำของคุณออกเป็นโซน การสับนี้เกิดขึ้นเนื่องจากในบางพื้นที่ของหน่วยความจำ 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 บิตเนื่องจากโซน HighMem ไม่มีอยู่ใน 64 บิต นอกจากนี้ในระบบ 64 บิตปกติจะถูกแมปถึง 4GB และเกินกว่าในขณะที่บน 32 บิตจะแมปได้ถึง 896Mb (แม้ว่าในกรณีของคุณเคอร์เนลรายงานเฉพาะการจัดการส่วนที่เล็กกว่านี้: - managed:587540kB.)

ความเป็นไปได้ที่จะบอกได้ว่าการจัดสรรนี้มาจากการมองที่บรรทัดแรกอีกครั้งgfp_mask=0x42d0บอกเราว่าการจัดสรรประเภทใดที่ทำ ไบต์สุดท้าย (0) บอกเราว่านี่เป็นการจัดสรรจากโซนปกติ ความหมาย GFP อยู่ในรวม / Linux / gfp.h

ลายน้ำโซนนี้ใช้

เมื่อหน่วยความจำเหลือน้อยการดำเนินการเพื่อเรียกคืนหน่วยความจำจะถูกระบุโดยลายน้ำ พวกเขามาปรากฏที่นี่: min:3044kB low:3804kB high:4564kB. หากหน่วยความจำว่างถึง 'ต่ำ' การสลับจะเกิดขึ้นจนกว่าเราจะผ่านเกณฑ์ 'สูง' หากหน่วยความจำถึง 'ขั้นต่ำ' เราต้องฆ่าสิ่งต่างๆเพื่อเพิ่มหน่วยความจำผ่าน 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-killer ถูกเรียกใช้หรือไม่ ทำไม?

ดังนั้นหากเราคำนึงถึงสิ่งเหล่านี้เราสามารถพูดได้ดังนี้

  • มีการพยายามจัดสรรที่ต่อเนื่อง 32kB จากโซนปกติ
  • มีหน่วยความจำว่างเพียงพอในโซนที่เลือก
  • มีหน่วยความจำสั่งซื้อ 3, 5 และ 6 13*32kB (MR) 1*128kB (R) 1*256kB (R)

ดังนั้นถ้ามีเป็นหน่วยความจำฟรีคำสั่งอื่น ๆ ที่สามารถตอบสนองการร้องขอ เกิดอะไรขึ้น?

มีการจัดสรรจากคำสั่งซื้อมากกว่าการตรวจสอบจำนวนหน่วยความจำว่างที่มีให้สำหรับคำสั่งซื้อนั้นหรือสูงกว่า เคอร์เนลได้อย่างมีประสิทธิภาพลบหน่วยความจำจากคำสั่งซื้อที่ต่ำกว่าทั้งหมดจากสายฟรีรวมแล้วดำเนินการตรวจสอบลายน้ำขั้นต่ำในสิ่งที่เหลือ

สิ่งที่เกิดขึ้นในกรณีของคุณคือการตรวจสอบหน่วยความจำว่างของเราสำหรับโซนนั้นที่เราต้องทำ

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

จำนวนหน่วยความจำว่างนี้จะถูกตรวจสอบกับminลายน้ำซึ่งก็คือ 3044 ดังนั้นในทางเทคนิคการพูด - คุณไม่มีหน่วยความจำว่างที่เหลือเพื่อทำการจัดสรรที่คุณร้องขอ และนี่คือเหตุผลที่คุณเรียกใช้ OOM-killer

แก้ไข

มีการแก้ไขสองประการ การอัพเกรดเป็น 64 บิตจะเป็นการแบ่งพาร์ติชั่นโซนของคุณโดยที่ 'ปกติ' คือ 4GB ถึง 36GB ดังนั้นคุณจะไม่ได้ 'การกำหนดค่าเริ่มต้น' การจัดสรรหน่วยความจำของคุณเป็นโซนที่สามารถแยกส่วนได้อย่างมาก ไม่ใช่ว่าคุณมีหน่วยความจำที่สามารถกำหนดแอดเดรสได้มากกว่าซึ่งแก้ไขปัญหานี้ (เพราะคุณใช้ PAE อยู่แล้ว) เพียงแค่ว่าโซนที่คุณเลือกมีหน่วยความจำที่สามารถกำหนดแอดเดรสได้มากกว่า

วิธีที่สอง (ซึ่งฉันไม่เคยทดสอบ) คือพยายามทำให้เคอร์เนลกระชับหน่วยความจำของคุณให้มากขึ้น

หากคุณเปลี่ยนค่าvm.extfrag_thresholdจาก 500 เป็น 100 มีแนวโน้มที่จะกระชับหน่วยความจำในความพยายามที่จะให้เกียรติการจัดสรรสูงลำดับ แม้ว่าฉันจะไม่เคยยุ่งกับค่านี้มาก่อน - มันก็จะขึ้นอยู่กับว่าดัชนีการกระจายตัวของคุณมีอยู่ในรูปแบบ/sys/kernel/debug/extfrag/extfrag_indexใด ฉันไม่มีกล่องในขณะนี้ที่มีเคอร์เนลใหม่พอที่จะดูสิ่งที่แสดงให้เห็นมากกว่านี้

หรือคุณสามารถเรียกใช้การเรียงลำดับของงาน cron บาง (นี้เป็นอย่างน่ากลัวน่าเกลียดน่ากลัว) /proc/sys/vm/compact_memoryหน่วยความจำขนาดกะทัดรัดด้วยตนเองด้วยตัวคุณเองโดยการเขียนลงใน

ในความจริงแล้วฉันไม่คิดว่าจะมีวิธีการปรับแต่งระบบเพื่อหลีกเลี่ยงปัญหานี้ซึ่งเป็นลักษณะของตัวจัดสรรหน่วยความจำในการทำงานด้วยวิธีนี้ การเปลี่ยนสถาปัตยกรรมของแพลตฟอร์มที่คุณใช้อาจเป็นทางออกเดียวที่สามารถแก้ไขได้

— Matthew Ife
แหล่งที่มา
การเข้าสู่ 64 บิตเป็นไปไม่ได้ในขณะนี้ ฉันต้องปรับแต่งระบบเพื่อไม่ให้เกิดข้อผิดพลาด
— seaquest
4
นี่เป็นคำตอบที่ยอดเยี่ยม มี upvote :)
— wzzrd
สวัสดี Mlfe คำตอบที่ยอดเยี่ยม ฉันอยากรู้เกี่ยวกับส่วนนี้ของโพสต์ของคุณ เคอร์เนลลบหน่วยความจำอย่างมีประสิทธิภาพจากคำสั่งซื้อที่ต่ำกว่าทั้งหมดจากสายฟรีทั้งหมดจากนั้นทำการตรวจสอบลายน้ำขั้นต่ำเกี่ยวกับสิ่งที่เหลืออยู่ - คุณมีซอร์สโค้ดที่เกี่ยวข้องซึ่งฉันสามารถผ่านได้หรือไม่ เพราะดีฉันได้จัดการปัญหา OOM มากมาย แต่ฉันไม่ได้เห็นเหตุผลนี้ในแหล่งที่มา บางทีฉันอาจพลาด คุณเห็นที่ไหนอยู่ดี oom_kill.c? หรือสิ่งอื่นใด
— Soham Chakraborty
2
รหัสอยู่ในหน่วย mm / page_alloc.c และทำในฟังก์ชัน __zone_watermark_ok
— Matthew Ife
@ShaamChakraborty หากคุณสนใจสิ่งนี้ฉันควรชี้ให้เห็นว่าคุณสามารถหาสาเหตุที่ทำให้ OOM ในเคอร์เนลได้โดยทำตามการติดตามสแต็กในเอาต์พุต OOM-killer ที่จัดมาให้ตามที่เป็นอยู่
— Matthew Ife
5

ปิดเริ่มต้น: คุณควรจริงๆไปสำหรับระบบปฏิบัติการ 64 บิต คุณมีเหตุผลที่ดีที่จะพักที่ 32- บิตที่นี่หรือไม่?

เป็นการยากที่จะวินิจฉัยปัญหานี้โดยไม่ได้มองระบบอย่างใกล้ชิดยิ่งขึ้นในช่วงเวลาที่ล้มเหลวดังนั้นโพสต์ (ด่วน) ของฉันจึงมุ่งเน้นไปที่ปัญหาหน่วยความจำในระบบ 32 บิตโดยทั่วไป ฉันพูดถึงการ 64- ​​บิตจะทำให้ทั้งหมดหายไป?

ปัญหาของคุณคือสามเท่า

อย่างแรกเลยแม้แต่ในเคอร์เนล PAE พื้นที่ต่อกระบวนการที่อยู่จะถูก จำกัด ที่ 4GiB [1] ซึ่งหมายความว่าอินสแตนซ์ปลาหมึกของคุณจะไม่สามารถกิน RAM มากกว่า 4GiB ต่อกระบวนการได้ ฉันไม่คุ้นเคยกับปลาหมึก แต่ถ้านี่คือพร็อกซีเซิร์ฟเวอร์หลักของคุณนั่นอาจไม่เพียงพอ

ประการที่สองในระบบ 32 บิตพร้อม RAM จำนวนมากหน่วยความจำจำนวนมากในสิ่งที่เรียกว่า '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 ไม่มีโซน HIGHMEM บนระบบ 64 บิต แก้ไขปัญหา.

แก้ไข: คุณสามารถดูที่นี่ [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/

— wzzrd
แหล่งที่มา
1
หน่วยความจำจะถูกจัดสรรจากโซนปกติ (ดู gfp_mask) ถึงแม้ว่าในช่วงเหลือบแรกโซนปกติมีหน่วยความจำว่างเพียงพอที่จะส่งมอบให้กับการจัดสรรนี้ ฉันมีคำอธิบายที่แท้จริงสำหรับเรื่องนี้ แต่ต้องมีการแก้ไขค่อนข้างยาวในโพสต์ของฉัน
— Matthew Ife
4

@MIfe ให้แล้วเขียนที่ดีขึ้นเกี่ยวกับวิธีการจัดสรรหน่วยความจำในเคอร์เนลได้รับการจัดการและยังให้คุณมีวิธีการแก้ปัญหาที่เหมาะสมเช่นการเปลี่ยนไปใช้ระบบปฏิบัติการ 64 บิตและสับที่น่ารังเกียจเช่นคู่มือหน่วยความจำผ่านการบดอัดใน/proc/sys/vm/compact_memorycron

2 เซ็นต์ของฉันจะเป็นวิธีแก้ปัญหาอื่นที่อาจช่วยคุณ:
ฉันสังเกตเห็นว่าคุณมีtcp_tso_segmentใน backtrace เคอร์เนลของคุณดังนั้นทำ:

# ethtool -K ethX tso off gso off lro off

สามารถลดแรงกดดันmmด้วยการบังคับให้ใช้คำสั่งซื้อที่ลดลง

ปล . รายการ offloads ทั้งหมดสามารถรับได้ผ่าน# ethtool -k ethX

— SaveTheRbtz
แหล่งที่มา
2
นี่เป็นข้อเสนอแนะที่ยอดเยี่ยม โหวตให้กับคุณ
— Matthew Ife
ข้อมูลนี้เป็นตัวชี้ที่ดีมาก ฉันจะตรวจสอบผลกระทบของ tso ด้วย
— seaquest
3

ความตื่นตระหนกคือเนื่องจาก sysctl "vm.panic_on_oom = 1" ถูกตั้งค่า - ความคิดคือการรีบูตระบบจะคืนค่าเป็นสถานะที่มีสติ คุณสามารถเปลี่ยนได้ใน sysctl.conf

ที่ด้านบนเราอ่านปลาหมึกที่เรียกว่า oom killer คุณอาจตรวจสอบการกำหนดค่าปลาหมึกและการใช้หน่วยความจำสูงสุด (หรือย้ายไปยังระบบปฏิบัติการ 64 บิต)

/ proc / meminfo แสดงโซนหน่วยความจำสูงที่ใช้งานอยู่ดังนั้นคุณจึงรันเคอร์เนลแบบ 32 บิตพร้อมหน่วยความจำ 36GB คุณจะเห็นได้ว่าในโซนปกติเพื่อให้ได้ตามความต้องการของหน่วยความจำของปลาหมึกเคอร์เนลสแกน 982 หน้าโดยไม่ประสบความสำเร็จ:

pages_scanned:982 all_unreclaimable? yes
— ramruma
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.