लिनक्स oom स्थिति

15

मेरे पास निरंतर ऊम और आतंक की स्थिति अनसुलझे हैं। मुझे यकीन नहीं है कि सिस्टम सभी RAM (36GB) को भर देता है। इस प्रणाली ने इस ओओएम स्थिति को क्यों ट्रिगर किया? मुझे संदेह है कि यह 32 बिट लाइनक्स सिस्टम में नीम जोन से संबंधित है। मैं कर्नेल पैनिक और ऊम-किलर से लॉग को कैसे एनालाइज कर सकता हूं?

सादर,

कर्नेल 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
मैंने इसे फिर से खोलने के लिए प्रश्न का पुन: निर्धारण किया है।
— समुद्र में
निम्नलिखित पंक्ति के लिए "CPU 0: hi: 0, btch: 1 usd: 0", क्या कोई जानता है कि "hi", "btch" और "usd" का क्या अर्थ है और उनकी इकाइयाँ क्या हैं?
— वाफलेमैन

जवाबों:

53

एक 'स्लेजहैमर' दृष्टिकोण हालांकि 64 बिट O / S (यह 32 बिट है) में अपग्रेड करना होगा क्योंकि जोनों का लेआउट अलग तरीके से किया जाता है।

ठीक है, इसलिए यहां मैं उत्तर देने का प्रयास करूंगा कि आपने यहां OOM का अनुभव क्यों किया है। यहाँ खेलने के लिए कई कारक हैं।

  • अनुरोध का क्रम आकार और कर्नेल कुछ क्रम आकारों का व्यवहार कैसे करता है।
  • जोन का चयन किया जा रहा है।
  • इस क्षेत्र का उपयोग वॉटरमार्क करता है।
  • क्षेत्र में विखंडन।

यदि आप खुद OOM को देखते हैं, तो स्पष्ट रूप से बहुत सारी मुफ्त मेमोरी उपलब्ध है लेकिन OOM- किलर को आमंत्रित किया गया था क्यों?

अनुरोध का क्रम आकार और कर्नेल कुछ क्रम आकारों का व्यवहार कैसे करता है

कर्नेल आदेश द्वारा मेमोरी आवंटित करता है। एक 'ऑर्डर' सन्निहित रैम का एक क्षेत्र है जिसे काम करने के अनुरोध के लिए संतुष्ट होना चाहिए। एल्गोरिथ्म का उपयोग करके आदेशों को परिमाण (इस प्रकार नाम क्रम) द्वारा व्यवस्थित किया जाता है2^(ORDER + 12) । तो, ऑर्डर 0 4096 है, ऑर्डर 1 8192 है, ऑर्डर 2 16384 है इसलिए आगे और आगे।

कर्नेल का हार्ड कोडित मान है जो 'उच्च क्रम' (>) मानता है PAGE_ALLOC_COSTLY_ORDER ) । यह 4 और ऊपर का ऑर्डर है (64kb या इससे ऊपर का ऑर्डर है)।

उच्च ऑर्डर कम ऑर्डर से अलग पेज आवंटन के लिए संतुष्ट हैं। यदि आधुनिक कर्नेल करेंगे तो मेमोरी को हथियाने में विफल रहने पर एक उच्च ऑर्डर आवंटन।

  • मेमोरी को डीफ़्रैग्मेन्ट करने के लिए मेमोरी कंप्रेशन रुटीन को चलाने का प्रयास करें।
  • अनुरोध को संतुष्ट करने के लिए कभी भी OOM- किलर को न बुलाएं।

आपका ऑर्डर आकार यहां सूचीबद्ध है

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

आदेश 3 निम्न-आदेश अनुरोधों में से सबसे अधिक है और (जैसा कि आप देखते हैं) इसे संतुष्ट करने के प्रयास में ओओएम-हत्यारा को आमंत्रित करता है।

ध्यान दें कि अधिकांश उपयोगकर्ता स्थान आवंटन उच्च-क्रम अनुरोधों का उपयोग नहीं करते हैं। आमतौर पर इसकी गिरी जिसमें स्मृति के सन्निहित क्षेत्रों की आवश्यकता होती है। इसका एक अपवाद तब हो सकता है जब उपयोगकर्ता स्थान का उपयोग कर रहा है - लेकिन ऐसा यहां नहीं है।

आपके मामले में आदेश 3 आवंटन को कर्नेल द्वारा नेटवर्क स्टैक में एक पैकेट को कतारबद्ध करने के लिए कहा जाता है - ऐसा करने के लिए 32kb आवंटन की आवश्यकता होती है।

जोन का चयन किया जा रहा है।

कर्नेल आपके मेमोरी क्षेत्रों को ज़ोन में विभाजित करता है। यह चॉपिंग इसलिए की जाती है क्योंकि x86 पर मेमोरी के कुछ क्षेत्रों को केवल कुछ हार्डवेयर द्वारा ही पता किया जा सकता है। पुराने हार्डवेयर केवल उदाहरण के लिए 'डीएमए' क्षेत्र में मेमोरी को संबोधित करने में सक्षम हो सकते हैं। जब हम कुछ मेमोरी आवंटित करना चाहते हैं, तो पहले एक ज़ोन चुना जाता है और केवल आवंटन निर्णय लेते समय इस ज़ोन से मुक्त मेमोरी का ही हिसाब लगाया जाता है।

जब तक मैं ज़ोन चयन एल्गोरिथ्म पर पूरी तरह से ज्ञान के लिए नहीं हूं, विशिष्ट उपयोग-मामला डीएमए से आवंटित करने के लिए नहीं है, लेकिन आमतौर पर सबसे कम पता योग्य क्षेत्र का चयन करें जो अनुरोध को संतुष्ट कर सकता है।

बहुत से ज़ोन की जानकारी 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

आपके पास जो क्षेत्र हैं, डीएमए, सामान्य और हाईमेम 32-बिट प्लेटफॉर्म को इंगित करते हैं, क्योंकि हाईमैट ज़ोन 64 बिट पर मौजूद नहीं है। 64 बिट सिस्टम पर भी सामान्य को 4GB और उससे आगे मैप किया जाता है, जबकि 32 बिट पर यह 896Mb तक मैप करता है (हालाँकि, आपके मामले में कर्नेल केवल इससे छोटे हिस्से को प्रबंधित करता है: -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

एक मेमोरी आवंटन के लिए संतुष्ट होना चाहिए अनुरोधित आकार या उच्चतर आवंटन में उपलब्ध मुफ्त मेमोरी चाहिए। बहुत सारे और बहुत सारे मुफ्त डेटा कम ऑर्डर में और उच्च आदेशों में कोई भी नहीं होने का मतलब है कि आपकी मेमोरी खंडित है। यदि आपको बहुत अधिक ऑर्डर आबंटन मिलता है तो इसके लिए (यहां तक ​​कि बहुत सारी मुफ्त मेमोरी के साथ) इसके लिए कोई उच्च-ऑर्डर पृष्ठ उपलब्ध नहीं होने के कारण संतुष्ट नहीं होना चाहिए। कर्नेल कम ऑर्डर पृष्ठों के बहुत सारे स्थानांतरित करके स्मृति (इसे मेमोरी संघनन कहा जाता है) कर सकते हैं ताकि वे पता योग्य राम स्थान में अंतराल न छोड़ें।

OOM- किलर को लगाया गया था? क्यों?

इसलिए, अगर हम इन बातों को ध्यान में रखते हैं, तो हम निम्नलिखित कह सकते हैं;

  • 32kB सन्निहित आवंटन का प्रयास किया गया था। सामान्य क्षेत्र से।
  • चयनित क्षेत्र में पर्याप्त मुक्त मेमोरी थी।
  • आदेश 3, 5 और 6 मेमोरी उपलब्ध था 13*32kB (MR) 1*128kB (R) 1*256kB (R)

इसलिए, यदि मुफ्त मेमोरी थी , तो अन्य ऑर्डर अनुरोध को पूरा कर सकते हैं। क्या हुआ?

ठीक है, उस आदेश या उच्चतर के लिए उपलब्ध मुफ्त मेमोरी की मात्रा की जांच करने की तुलना में ऑर्डर से आवंटन करना अधिक है। कर्नेल प्रभावी रूप से कुल फ्री लाइन से सभी निचले ऑर्डर से मेमोरी को घटाता है और फिर जो बचा है उस पर न्यूनतम वॉटरमार्क चेक करता है।

आपके मामले में क्या होता है यह उस क्षेत्र के लिए हमारी मुफ्त मेमोरी की जांच करना है जो हमें करना चाहिए।

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

यह मुफ्त मेमोरी की मात्रा minवॉटरमार्क के खिलाफ जांची जाती है, जो 3044 है। इस प्रकार, तकनीकी रूप से बोलना - आपके पास आपके द्वारा अनुरोधित आवंटन को करने के लिए कोई मुफ्त मेमोरी नहीं है। और यही कारण है कि आपने OOM- किलर को आमंत्रित किया।

फिक्सिंग

दो फिक्स हैं। 64 बिट में अपग्रेड करने से आपके ज़ोन के विभाजन में बदलाव आता है, जैसे कि 'नॉर्मल' 4GB 36GB तक होता है, इसलिए आप अपने मेमोरी आवंटन को 'डिफॉल्टिंग' के रूप में अंजाम तक पहुँचाते हैं, जो इतना भारी खंडित हो सकता है। यह नहीं है कि आपके पास अधिक पता योग्य मेमोरी है जो इस समस्या को ठीक करती है (क्योंकि आप पहले से ही पीएई का उपयोग कर रहे हैं), केवल यह कि आपके द्वारा चुने गए क्षेत्र में अधिक पता योग्य मेमोरी है।

दूसरा तरीका (जिसका मैंने कभी परीक्षण नहीं किया है) यह है कि कर्नेल को अधिक आक्रामक रूप से अपनी मेमोरी को कॉम्पैक्ट करने का प्रयास करें।

यदि आप vm.extfrag_threshold500 से 100 के मूल्य को बदलते हैं, तो उच्च-ऑर्डर आवंटन का सम्मान करने के प्रयास में इसकी कॉम्पैक्ट मेमोरी की अधिक संभावना है। हालाँकि, मैंने पहले कभी इस मूल्य के साथ खिलवाड़ नहीं किया है - यह इस बात पर भी निर्भर करेगा कि आपका विखंडन सूचकांक क्या उपलब्ध है /sys/kernel/debug/extfrag/extfrag_index। मेरे पास इस समय एक बॉक्स नहीं है जिसमें यह देखने के लिए एक नया पर्याप्त कर्नेल है कि इससे अधिक की पेशकश करने के लिए क्या दिखाता है।

वैकल्पिक रूप से आप कुछ प्रकार की क्रोन जॉब चला सकते हैं (यह बुरी तरह से, बुरी तरह से बदसूरत है) मैन्युअल रूप से कॉम्पैक्ट मेमोरी में लिखकर /proc/sys/vm/compact_memory।

सभी ईमानदारी से, हालांकि, मुझे नहीं लगता कि वास्तव में इस समस्या से बचने के लिए सिस्टम को ट्यून करने का एक तरीका है - इस तरह से काम करने के लिए मेमोरी एलोकेटर की प्रकृति। आपके द्वारा उपयोग किए जाने वाले मंच की वास्तुकला को बदलना शायद एकमात्र मौलिक समाधान है।

— मैथ्यू इफ
स्रोत
फिलहाल ६४ बिट में जाना असंभव है। मुझे त्रुटि प्राप्त करने के लिए सिस्टम को ट्यून करना होगा।
— सीक्वेस्ट
4
यह एक कमाल का जवाब है।
— अपवोट करें
हाय Mlfe, उत्कृष्ट जवाब। मुझे आपकी पोस्ट के इस हिस्से के बारे में उत्सुकता है। "कर्नेल कुल फ्री लाइन से सभी निचले ऑर्डर से मेमोरी को प्रभावी रूप से घटाता है और फिर जो कुछ बचा है उस पर न्यूनतम वॉटरमार्क चेक करता है।" - क्या आपके पास प्रासंगिक स्रोत कोड है जिससे मैं गुजर सकता हूं? क्योंकि, ठीक है, मैंने कई OOM मुद्दों को निपटाया है, लेकिन मैंने इस तर्क को स्रोत में नहीं देखा है। शायद, मैं चूक गया। वैसे भी आप कहां देख रहे हैं? oom_kill.c? या फिर कुछ और?
— सोहम चक्रवर्ती 15
2
कोड mm / page_alloc.c में है और फ़ंक्शन में किया गया है __zone_watermark_ok
— मैथ्यू इफ
@SohamChakraborty यदि आप इस सामान में रुचि रखते हैं, तो मुझे यह भी इंगित करना चाहिए कि आप यह पता लगा सकते हैं कि OOM- किलर आउटपुट में स्टैक ट्रेस का अनुसरण करके कर्नेल में OOM का क्या कारण है, जैसा कि यहाँ है।
— मैथ्यू इफ
5

प्रारंभ से: आपको वास्तव में 64-बिट ऑपरेटिंग सिस्टम के लिए जाना चाहिए । क्या आपके पास 32-बिट पर रहने का एक अच्छा कारण है?

सिस्टम को अधिक बारीकी से देखे बिना इस समस्या का निदान करना मुश्किल है, अधिमानतः यह विफल होने के समय के आसपास है, इसलिए मेरी (त्वरित) पोस्ट 32-बिट सिस्टम पर मेमोरी के मुद्दों पर अधिक या कम उदारतापूर्वक लक्षित है। क्या मैंने उल्लेख किया है कि 64-बिट होने से यह सब खत्म हो जाएगा?

आप समस्या तीन गुना है।

सबसे पहले, यहां तक ​​कि एक पीएई कर्नेल पर, प्रति प्रक्रिया पता स्थान 4GiB [1] तक सीमित है। इसका मतलब यह है कि आपका स्क्वीड उदाहरण कभी भी प्रति प्रोसेस 4 जीआईबी से अधिक रैम खाने में सक्षम नहीं होगा। मैं स्क्वीड से परिचित नहीं हूं, लेकिन अगर यह आपका मुख्य प्रॉक्सी सर्वर है, तो यह पर्याप्त नहीं हो सकता है।

दूसरा, 32-बिट सिस्टम पर विशाल मात्रा में रैम के साथ, जिसे 'ZONE_NORMAL' कहा जाता है, में बहुत सी मेमोरी का उपयोग डेटा संरचनाओं को संग्रहीत करने के लिए किया जाता है, जिन्हें ZONE_HIGHMEM में मेमोरी का उपयोग करने की आवश्यकता होती है। इन डेटास्ट्रक्चर को ZONE_HIGHMEM में स्थानांतरित नहीं किया जा सकता है, क्योंकि कर्नेल जिस मेमोरी का उपयोग करता है, वह स्वयं के उद्देश्यों के लिए हमेशा ZONE_NORMAL (पहले 1GiB-ish में) होना चाहिए। ZONE_HIGHMEM में बहुत अधिक मेमोरी (आपके मामले में, बहुत कुछ), यह एक समस्या बन जाती है, क्योंकि कर्नेल को ZONE_HIGHMEM को प्रबंधित करने के लिए ZONE_NORMAL से अधिक से अधिक मेमोरी की आवश्यकता होती है। जैसा कि ZONE_NORMAL में मुफ्त मेमोरी की मात्रा सूख जाती है, आपका सिस्टम कुछ कार्यों में विफल हो सकता है, क्योंकि ZONE_NORMAL वह जगह है जहां 32-बिट सिस्टम पर बहुत अधिक सामान होता है। उदाहरण के लिए, सभी कर्नेल संबंधित मेमोरी ऑपरेशन;)

तीसरा, भले ही ZONE_NORMAL में कुछ मेमोरी बची हो (मैं आपके लॉग के बारे में विस्तार से नहीं जाना है), कुछ मेमोरी ऑपरेशंस में अनफैग्मेंटेड मेमोरी की आवश्यकता होगी। उदाहरण के लिए, यदि आपकी सभी मेमोरी वास्तव में छोटे-छोटे टुकड़ों में बँटी हुई है, तो कुछ ऑपरेशन जिन्हें इससे अधिक की आवश्यकता है, वे विफल हो जाएंगे। [३] आपके लॉग पर एक संक्षिप्त नज़र ZONE_DMA और ZONE_NORMAL में विखंडन की एक महत्वपूर्ण मात्रा को दर्शाता है।

संपादित करें: ऊपर दिए गए Mlfe के उत्तर में इस बात का उत्कृष्ट विवरण है कि यह कैसे विस्तार से काम करता है।

दोबारा: 64-बिट सिस्टम पर, सभी मेमोरी ZONE_NORMAL में है। 64-बिट सिस्टम पर कोई HighMEM ज़ोन नहीं है। समस्या सुलझ गयी।

संपादित करें: आप यहाँ देख सकते हैं [4] यह देखने के लिए कि क्या आप अपने महत्वपूर्ण प्रक्रियाओं को अकेले छोड़ने के लिए ऊम-हत्यारा बता सकते हैं। यह सब कुछ हल नहीं करेगा (यदि कुछ भी हो), लेकिन यह एक कोशिश के लायक हो सकता है।

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

[२] http://www.redhat.com/archives/rhelv5-list/2008-Seture/msg00237.html और https://access.redhat.com/site/documentation/en-US/Red_Hat_Ennprise_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

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

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

— wzzrd
स्रोत
1
मेमोरी को सामान्य ज़ोन (gfp_mask देखें) से आवंटित किया जा रहा है, यद्यपि पहली नज़र में सामान्य को इस आवंटन के लिए पर्याप्त स्वतंत्र मेमोरी है। मेरे पास इसके लिए एक वास्तविक स्पष्टीकरण है, लेकिन इसके लिए मेरी पोस्ट के लिए काफी लंबा संपादन आवश्यक है।
— मैथ्यू इफ
4

@MIfe ने पहले से ही उत्कृष्ट लेखन प्रदान किया है कि कैसे कर्नेल में मेमोरी आवंटन को संभाला जाता है और आपको 64-बिट OS पर स्विच करने और मैनुअल मेमोरी कंपैक्शन जैसे नॉटी हैक जैसे उचित समाधान भी प्रदान करता /proc/sys/vm/compact_memoryहै cron।

मेरे 2 सेंट एक और वर्कअराउंड होंगे जो आपकी मदद कर सकते हैं:
मैंने देखा है कि आपके पास tcp_tso_segmentकर्नेल बैकट्रेस है, इसलिए ऐसा करना:

# ethtool -K ethX tso off gso off lro off

mmकम आदेशों का उपयोग करने के लिए मजबूर करके दबाव कम कर सकता है ।

पुनश्च । सभी ऑफलोड की सूची के माध्यम से प्राप्त किया जा सकता है# ethtool -k ethX

— SaveTheRbtz
स्रोत
2
यह एक शानदार सुझाव है। आप तक पहुँचते हैं।
— मैथ्यू इफ
यह जानकारी बहुत अच्छा सूचक है। मैं त्सो के प्रभाव का भी निरीक्षण करूंगा।
— समुद्र में
3

घबराहट इसलिए है क्योंकि sysctl "vm.panic_on_oom = 1" सेट है - विचार यह है कि सिस्टम को रिबूट करने से यह एक स्थिति में वापस आ जाता है। आप इसे sysctl.conf में बदल सकते हैं।

ठीक ऊपर हमने स्क्वीड इनवॉइस ऊम किलर पढ़ा। आप अपने स्क्वीड कॉन्फ़िगरेशन और इसके अधिकतम मेमोरी उपयोग की जांच कर सकते हैं (या सिर्फ 64-बिट ओएस पर जाएं)।

/ proc / meminfo उपयोग में उच्च मेमोरी ज़ोन दिखाता है, इसलिए आप 36GB मेमोरी के साथ 32-बिट कर्नेल चला रहे हैं। आप यह भी देख सकते हैं कि सामान्य क्षेत्र में, स्क्वीड की स्मृति की मांग को पूरा करने के लिए, कर्नेल ने बिना सफलता के 982 पृष्ठ स्कैन किए:

pages_scanned:982 all_unreclaimable? yes
— ramruma
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.