লিনাক্স ওম অবস্থা

15

আমার অবিচ্ছিন্ন ও অহঙ্কার পরিস্থিতি অমীমাংসিত। আমি নিশ্চিত নই যে সিস্টেমটি সমস্ত র‌্যাম (36 জিবি) পূরণ করেছে। কেন এই সিস্টেম এই ওম পরিস্থিতিকে ট্রিগার করেছিল? আমি এটি 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
ওহে লোকেরা - আমি এই প্রশ্নটি বন্ধ করার কোনও কারণ দেখতে পাচ্ছি না। এটি একটি আকর্ষণীয় ওম-সমস্যা।
— নীল
1
এটিকে আবার খোলার জন্য আমি প্রশ্নের উত্তর দিয়েছি।
— সমুদ্র সৈকত
নিম্নলিখিত লাইন "সিপিইউ 0: হাই: 0, বিটিচ: 1 ইউএসডি: 0" এর জন্য, কেউ কি জানেন যে "হাই", "বিটিচ" এবং "ইউএসডি" কী এবং তাদের ইউনিটগুলি কী?
— ওয়াফলম্যান

উত্তর:

53

একটি 'স্লেজহ্যামার' পন্থা যদিও bit৪ বিট ও / এস-তে আপগ্রেড করা হবে (এটি 32 বিট) কারণ অঞ্চলগুলির বিন্যাসটি ভিন্নভাবে সম্পন্ন হয়।

ঠিক আছে, সুতরাং এখানে আপনি কেন একটি OOM অভিজ্ঞতা পেয়েছেন তা উত্তর দেওয়ার চেষ্টা করব। এখানে খেলতে বেশ কয়েকটি কারণ রয়েছে।

  • অনুরোধের অর্ডার আকার এবং কার্নেল কীভাবে নির্দিষ্ট অর্ডার মাপের আচরণ করে।
  • জোনটি নির্বাচিত হচ্ছে।
  • এই অঞ্চলটি যে ওয়াটারমার্কগুলি ব্যবহার করে।
  • জোনে বিভাজন।

আপনি যদি ও ওএম এর দিকে তাকান তবে স্পষ্টতই প্রচুর ফ্রি মেমরি পাওয়া যায় তবে ওওএম-হত্যাকারীকে অনুরোধ করা হয়েছিল? কেন?

অনুরোধের অর্ডার আকার এবং কার্নেল কীভাবে নির্দিষ্ট অর্ডার মাপের আচরণ করে

কার্নেল আদেশ দ্বারা মেমরি বরাদ্দ করে। একটি 'অর্ডার' সামঞ্জস্যপূর্ণ র‌্যামের একটি অঞ্চল যা কাজের অনুরোধের জন্য সন্তুষ্ট হতে হবে। অ্যালগোরিদম ব্যবহার করে প্রস্থের আদেশ (এভাবে নামের ক্রম) দ্বারা অর্ডারগুলি সাজানো হয় 2^(ORDER + 12)। সুতরাং, অর্ডার 0 হ'ল 4096, অর্ডার 1 8192, অর্ডার 2 16384 এবং আরও অনেক কিছু।

কার্নেলের একটি 'হাই অর্ডার' (> PAGE_ALLOC_COSTLY_ORDER) বিবেচনা করা হয় তার একটি হার্ড কোডিং মান রয়েছে । এটি অর্ডার 4 এবং উপরে (k৪ কেবি বা উচ্চতর উচ্চ অর্ডার)।

উচ্চ আদেশগুলি কম আদেশের চেয়ে পৃথকভাবে পৃষ্ঠা বরাদ্দের জন্য সন্তুষ্ট। একটি উচ্চ অর্ডার বরাদ্দ যদি এটি মেমরিটি ধরতে ব্যর্থ হয় তবে আধুনিক কার্নেলগুলিতে।

  • মেমরিটিকে ডিফ্র্যাগ করার জন্য মেমরিটি কমপ্যাকশন রুটিন চালানোর চেষ্টা করুন।
  • অনুরোধটি সন্তুষ্ট করতে কখনই ওওএম-হত্যাকারীকে কল করবেন না।

আপনার অর্ডার আকার এখানে তালিকাভুক্ত করা হয়

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-এ নির্দিষ্ট মেমরির কিছু অঞ্চল কেবল নির্দিষ্ট হার্ডওয়্যার দ্বারা চিহ্নিত করা যায়। পুরানো হার্ডওয়্যার উদাহরণস্বরূপ কেবল 'ডিএমএ' জোনে মেমরিটিকে সম্বোধন করতে সক্ষম হতে পারে। আমরা কিছু মেমরি বরাদ্দ চান, তখন, প্রথম একটি জোন মনোনীত করা হয় এবং শুধুমাত্র এই জোন থেকে বিনামূল্যে মেমরির একটি বরাদ্দ সিদ্ধান্ত নেওয়ার জন্য দায়ী করা হয়।

যদিও আমি জোন নির্বাচন অ্যালগরিদম সম্পর্কে সম্পূর্ণ জ্ঞানের উপর নির্ভর করি না, সাধারণত ইউজ-কেসটি কখনই ডিএমএ থেকে বরাদ্দ করা হয় না, তবে সাধারণত অনুরোধটি সন্তুষ্ট করতে পারে এমন সর্বনিম্ন ঠিকানাযুক্ত অঞ্চল নির্বাচন করতে হয়।

ওওএম এর সময় প্রচুর জোনের তথ্য ছড়িয়ে যায় যা এখান থেকে সংগ্রহও করা যায় /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 বিট-তে বিদ্যমান নয়। এছাড়াও bit৪ বিট সিস্টেমে নরমালটি ৪ জিবিতে ম্যাপ করা হয় এবং এরপরে 32২ বিট-এ এটি 896 এমবি অবধি ম্যাপ করা হয় (যদিও, আপনার ক্ষেত্রে কার্নেল কেবল এর চেয়ে কম অংশ পরিচালনা করে: - managed:587540kB।)

এই প্রথম বরাদ্দটি আবার প্রথম লাইনের দিকে তাকিয়ে এই বরাদ্দটি কোথা থেকে এসেছে তা বলা সম্ভব, gfp_mask=0x42d0কী ধরণের বরাদ্দ করা হয়েছিল। শেষ বাইট (0) আমাদের জানায় যে এটি সাধারণ অঞ্চল থেকে বরাদ্দ। জিএফপি অর্থগুলি অন্তর্ভুক্ত / লিনাক্স / জিএফপি এইচ অন্তর্ভুক্ত ।

এই অঞ্চলটি যে ওয়াটারমার্কগুলি ব্যবহার করে।

যখন স্মৃতিশক্তি কম থাকে, তখন এটি দাবি করার ক্রিয়াগুলি ওয়াটারমার্ক দ্বারা নির্দিষ্ট করা হয়। সেগুলি এখনে দেখানো: min:3044kB low:3804kB high:4564kB। যদি ফ্রি মেমরিটি 'কম' এ পৌঁছে যায়, তবে আমরা 'উচ্চ' প্রান্তিকতা অতিক্রম না করা পর্যন্ত অদলবদল হবে। যদি মেমরিটি 'মিনিটে' পৌঁছে যায় তবে ওওএম-হত্যাকারীর মাধ্যমে মেমরিটি মুক্ত করতে আমাদের জিনিসগুলি মেরে ফেলতে হবে।

জোনে বিভাজন।

মেমোরির একটি নির্দিষ্ট ক্রমের জন্য একটি অনুরোধটি সন্তুষ্ট করা যায় কিনা তা দেখার জন্য, কার্নেলটি কতগুলি নিখরচায় পৃষ্ঠাগুলি এবং প্রতিটি অর্ডারের জন্য উপলব্ধ। এই পাঠযোগ্য /proc/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

মেমরি বরাদ্দ সন্তুষ্ট করার জন্য অনুরোধ করা অর্ডার আকারে বা আরও বেশি বরাদ্দে মুক্ত মেমরি উপলব্ধ থাকতে হবে। লো অর্ডারগুলিতে প্রচুর এবং প্রচুর ফ্রি ডেটা এবং উচ্চতর অর্ডারে কোনওোটাই না হওয়া মানে আপনার স্মৃতিটি খণ্ডিত। যদি আপনি একটি উচ্চ-অর্ডারের বরাদ্দ পান তবে এটির জন্য উচ্চ-অর্ডার পৃষ্ঠা নেই বলে এটি সন্তুষ্ট না হওয়ার জন্য এটি সম্ভব (প্রচুর ফ্রি মেমরি সহ )ও সম্ভব হয়। প্রচুর কম অর্ডার পৃষ্ঠাগুলি চারপাশে সরানোর মাধ্যমে কার্নেল মেমরিটিকে ডিফ্র্যাগমেন্ট করতে পারে (এটিকে মেমোরি কমপ্যাকশন বলা হয়) যাতে তারা ঠিকানাযোগ্য রামের জায়গায় ফাঁক ছেড়ে না দেয়।

ওওএম-হত্যাকারীর ডাক দেওয়া হয়েছিল? কেন?

সুতরাং, আমরা যদি এই বিষয়গুলিকে বিবেচনা করি তবে আমরা নিম্নলিখিতটি বলতে পারি;

  • একটি 32 কেবি সংলগ্ন বরাদ্দের চেষ্টা করা হয়েছিল। সাধারণ অঞ্চল থেকে।
  • নির্বাচিত জোনে পর্যাপ্ত ফ্রি মেমরি ছিল।
  • অর্ডার 3, 5 এবং 6 মেমরি উপলব্ধ ছিল 13*32kB (MR) 1*128kB (R) 1*256kB (R)

সুতরাং, যদি সেখানে ছিল বিনামূল্যে মেমরি, অন্যান্য আদেশ পারে অনুরোধ সন্তুষ্ট। কি হলো?

ঠিক আছে, অর্ডার থেকে বরাদ্দ করার মতো আরও অনেক কিছুই রয়েছে সেই অর্ডার বা তার চেয়ে বেশি উচ্চতর মেমরির পরিমাণের জন্য যাচাই করা। কার্নেলটি মোট বিনামূল্যে লাইন থেকে সমস্ত নিম্নতর অর্ডার থেকে কার্যকরভাবে মেমরিটি বিয়োগ করে এবং তারপরে কী রয়েছে তা নূন্যতম ওয়াটারমার্ক চেক করে।

আপনার ক্ষেত্রে যা ঘটে তা হ'ল আমাদের অবশ্যই সেই অঞ্চলের জন্য আমাদের ফ্রি মেমরি পরীক্ষা করা।

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

এই পরিমাণ নিখরচায় মেমোরিটি minওয়াটারমার্কের বিপরীতে চেক করা হয় , যা 3044। এইভাবে, প্রযুক্তিগতভাবে বলতে গেলে - আপনার অনুরোধের বরাদ্দটি করতে কোনও মুক্ত মেমরি অবশিষ্ট নেই। এবং এ কারণেই আপনি ওওএম-হত্যাকারীকে ডাকলেন।

স্থাপন করা

দুটি ফিক্স আছে। Bit৪ বিট আপগ্রেড করার ফলে আপনার জোনের বিভাজনে পরিবর্তন হয় যেমন 'নরমাল' ৩ জিবি পর্যন্ত ৩ জিবি হয়, সুতরাং আপনি আপনার মেমরির বরাদ্দকে এমন একটি অঞ্চলে 'ডিফল্ট' করতে পারবেন না যা এত বেশি খণ্ডিত হতে পারে। এটি এমন নয় যে আপনার আরও সম্বোধনযোগ্য মেমরি রয়েছে যা এই সমস্যাটিকে সংশোধন করে (কারণ আপনি ইতিমধ্যে পিএই ব্যবহার করছেন) কেবলমাত্র আপনি যে অঞ্চলটি বেছে নিয়েছেন তার থেকে বেশি ঠিকানাযোগ্য স্মৃতি রয়েছে।

দ্বিতীয় উপায় (যা আমি কখনই পরীক্ষা করিনি) হ'ল আপনার স্মৃতিটিকে আরও আক্রমণাত্মকভাবে কমপ্যাক্ট করার জন্য কার্নেলটি পাওয়ার চেষ্টা করা।

আপনি যদি vm.extfrag_threshold500 থেকে 100 এর মান পরিবর্তন করেন তবে উচ্চ-অর্ডার বরাদ্দের সম্মানের প্রয়াসে স্মৃতি সংক্ষিপ্ত হওয়ার সম্ভাবনা বেশি। যদিও, আমি এই মানটির সাথে আগে কখনও গণ্ডগোল করিনি - এটি আপনার ফ্র্যাগমেন্টেশন ইনডেক্সটি যা পাওয়া যায় তার উপরও নির্ভর করবে /sys/kernel/debug/extfrag/extfrag_index। এই মুহুর্তে একটি নতুন পর্যাপ্ত কার্নেল সহ একটি বাক্স নেই যা এটি এর চেয়ে আরও বেশি কী অফার করে তা দেখায়।

অন্যথায় আপনি মধ্যে লিখে নিজে কম্প্যাক্ট মেমরির নিজেকে (এই ভয়ঙ্করভাবে, ভয়ঙ্করভাবে কুশ্রী হয়) ক্রন কাজ কিছু বাছাই চালাতে পারে /proc/sys/vm/compact_memory।

যদিও সমস্ত সত্যই, আমি মনে করি না যে সমস্যাটি এড়াতে সিস্টেম টিউন করার সত্যিই কোন উপায় আছে - এটি এইভাবে কাজ করার জন্য মেমরির বরাদ্দকারীর প্রকৃতি। আপনার ব্যবহৃত প্ল্যাটফর্মটির আর্কিটেকচার পরিবর্তন করা সম্ভবত একমাত্র মৌলিক সমাধানযোগ্য সমাধান।

— ম্যাথু ইফ
সূত্র
এই মুহুর্তে 64 বিট অসম্ভব। ত্রুটি না পেতে সিস্টেম টিউন করতে হবে।
— সমুদ্র সৈকত
4
এটি একটি দুর্দান্ত উত্তর। একটি
— উপভোগ করুন
হাই Mlfe, দুর্দান্ত উত্তর। আমি আপনার পোস্টের এই অংশ সম্পর্কে কৌতূহলী। "কার্নেল কার্যকরভাবে নিখরচায় মোট লাইন থেকে সমস্ত নিম্ন অর্ডার থেকে মেমরিটি বিয়োগ করে এবং তারপরে কী রয়েছে তা নূন্যতম ওয়াটারমার্ক চেক করে।" - আমি যে প্রাসঙ্গিক উত্স কোডটি দিয়ে যেতে পারি তা কি আপনার কাছে রয়েছে? কারণ, ভাল, আমি প্রচুর OOM ইস্যুগুলি মোকাবিলা করেছি তবে উত্সটিতে এই যুক্তিটি আমি দেখিনি। সম্ভবত, আমি মিস করেছি। তুমি কোথায় দেখছ? oom_kill.c? নাকি অন্য কিছু?
— সোহম চক্রবর্তী
2
কোডটি মিমি / পৃষ্ঠার_লোক.সি তে হয় এবং __zone_watermark_ok ফাংশনে সম্পন্ন হয়
— ম্যাথু
@ সোহম চক্রবর্তী যদি আপনার এই জিনিসগুলির প্রতি আগ্রহী হয় তবে আমারও এটি উল্লেখ করা উচিত যে ওওএম-কিলার আউটপুট সরবরাহ করা স্ট্যাক ট্রেস অনুসরণ করে কার্নেলটিতে কোনও OOM কী কারণ হয়ে যায় তা নির্ধারণ করতে পারেন, যেমন এখানে রয়েছে case
— ম্যাথু ইফ
5

শুরুটি বন্ধ: আপনার সত্যিই a৪-বিট অপারেটিং সিস্টেমের জন্য যাওয়া উচিত । আপনার এখানে 32-বিট থাকার উপযুক্ত কারণ আছে?

সিস্টেমে আরও ঘনিষ্ঠভাবে নজর দেওয়া ছাড়া এই সমস্যাটি নির্ণয় করা কঠিন, প্রায়শই ব্যর্থ হওয়া সময়ের আশেপাশে, তাই আমার (দ্রুত) পোস্টটি কমপক্ষে 32-বিট সিস্টেমে মেমরির সমস্যাগুলিকে লক্ষ্য করে। আমি কি উল্লেখ করেছি 64৪-বিট যাওয়ার ফলে সমস্ত কিছু দূরে চলে যাবে?

আপনার সমস্যাটি তিনগুণ।

প্রথমত, এমনকি একটি PAE কার্নেলে, প্রতি প্রক্রিয়া ঠিকানার স্থান 4GiB [1] এর মধ্যে সীমাবদ্ধ। এর অর্থ হ'ল আপনার স্কুইড দৃষ্টান্তটি প্রক্রিয়া প্রতি 4GiB এর চেয়ে বেশি র‍্যাম খেতে সক্ষম হবে না। আমি স্কুইডের সাথে তেমন পরিচিত নই, তবে এটি যদি আপনার মূল প্রক্সি সার্ভার হয় তবে তা সম্ভবত যথেষ্ট নাও হতে পারে।

দ্বিতীয়ত, বিপুল পরিমাণ র‍্যাম সহ 32-বিট সিস্টেমে, 'জোনোনআরমাল' নামে পরিচিত যা প্রচুর পরিমাণে মেমোরি ZONE_HIGHMEM এ মেমরি ব্যবহার করতে প্রয়োজনীয় ডেটা স্ট্রাকচার সঞ্চয় করতে ব্যবহৃত হয়। এই ডেটাস্ট্রাকচারটি নিজেরাই ZONE_HIGHMEM এ স্থানান্তরিত করা যায় না, কারণ কার্নেলটি তার নিজস্ব উদ্দেশ্যে যা মেমরি ব্যবহার করে তা সর্বদা ZONE_NORMAL (অবশ্যই প্রথম 1 জিআইবি-ইশ-তে) থাকতে হবে। ZONE_HIGHMEM এ আপনার যত বেশি মেমরি রয়েছে (এটি আপনার ক্ষেত্রে অনেক বেশি) এটি একটি সমস্যা হয়ে ওঠে, কারণ কার্নেলের পরে ZONE_HIGHMEM পরিচালনার জন্য ZONE_NORMAL থেকে আরও বেশি মেমরির প্রয়োজন হয়। ZONE_NORMAL এ মুক্ত মেমরির পরিমাণ শুকিয়ে যাওয়ার সাথে সাথে আপনার সিস্টেমটি কিছু কাজে ব্যর্থ হতে পারে, কারণ ZONE_NORMAL হল যেখানে 32-বিট সিস্টেমে প্রচুর স্টাফ ঘটে। কার্নেল সম্পর্কিত সমস্ত মেমরি অপারেশন, উদাহরণস্বরূপ;)

তৃতীয়ত, ZONE_NORMAL- তে কিছু স্মৃতি বাকী থাকলেও (আমি আপনার লগগুলি বিশদে বিস্তারিতভাবে দেখিনি), কিছু মেমরি ক্রিয়াকলাপের জন্য অবিবাহিত মেমরির প্রয়োজন হবে। উদাহরণস্বরূপ, আপনার সমস্ত স্মৃতি যদি সত্যিই ছোট ছোট টুকরো টুকরো টুকরো টুকরো টুকরো হয়ে যায় তবে কিছু ক্রিয়াকলাপ যা এর চেয়ে বেশি প্রয়োজন তা ব্যর্থ হবে। [3] আপনার লগগুলির একটি সংক্ষিপ্ত বিবরণ ZONE_DMA এবং ZONE_NORMAL এ বিভক্ত হওয়ার যথেষ্ট পরিমাণের পরিমাণ দেখায়।

সম্পাদনা করুন: উপরে এমএলফির উত্তরে এটি কীভাবে বিশদভাবে কাজ করে তার একটি দুর্দান্ত ব্যাখ্যা রয়েছে।

আবার: 64৪-বিট সিস্টেমে সমস্ত মেমরি ZONE_NORMAL এ থাকে। -৪-বিট সিস্টেমে কোনও হাইমেম জোন নেই। সমস্যা সমাধান.

সম্পাদনা করুন: আপনি ওوم-কিলারকে আপনার গুরুত্বপূর্ণ প্রক্রিয়াগুলি একা ছেড়ে যেতে বলতে পারেন কিনা তা দেখতে আপনি এখানে [4] একবার দেখতে পারেন। এটি সবকিছু সমাধান করবে না (যদি কিছু হয় তবে) তবে এটি চেষ্টা করার মতো হতে পারে।

[1] http://en.wikedia.org/wiki/Physical_address_extension# ডিজাইন

[২] http://www.redhat.com/archives/rhelv5-list/2008- সেপ্টেম্বর /msg00237.html এবং https://access.redhat.com/site/docamentation/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

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

— wzzrd
সূত্র
1
সাধারণ জোন থেকে মেমরি বরাদ্দ করা হচ্ছে (gfp_mask দেখুন), প্রথম নজরে জোনে যদিও এই বরাদ্দটি কমিট করার জন্য পর্যাপ্ত ফ্রি মেমরি রয়েছে। আমার এটির জন্য একটি বাস্তব ব্যাখ্যা আছে তবে এটি আমার পোস্টে বেশ দীর্ঘ সম্পাদনা প্রয়োজন।
— ম্যাথু আইফে
4

@ মিফ ইতিমধ্যে কীভাবে কার্নেলের মধ্যে মেমরির বরাদ্দগুলি পরিচালনা করা হয় তা সম্পর্কে দুর্দান্ত লেখার ব্যবস্থা করেছিলেন এবং আপনাকে 64৪ -বিট ওএসে স্যুইচ করার মতো সঠিক সমাধান এবং /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
এটি একটি উজ্জ্বল পরামর্শ। আপভোট আপনি।
— ম্যাথু ইফ
এই তথ্যটি খুব ভাল পয়েন্টার। আমি tso এর প্রভাবও পরিদর্শন করব।
— সমুদ্র সৈকত
3

আতঙ্কটি হ'ল কারণ সিস্টেমে "vm.panic_on_oom = 1" সেট করা আছে - ধারণাটি হ'ল সিস্টেমটি পুনরায় বুট করা একটি বুদ্ধিমান অবস্থায় ফিরে আসে। আপনি এটি sysctl.conf এ পরিবর্তন করতে পারেন।

ডানদিকের উপরে আমরা স্কুইড চালিত ওম কিলারটি পড়ি read আপনি আপনার স্কুইড কনফিগারেশন এবং এর সর্বাধিক মেমরির ব্যবহার পরীক্ষা করতে পারেন (বা কেবল একটি -৪-বিট ওএসে স্থানান্তরিত করুন)।

/ proc / meminfo ব্যবহারের ক্ষেত্রে উচ্চ মেমরি জোন দেখায়, তাই আপনি 36GB মেমরির সাথে একটি 32-বিট কার্নেল চালাচ্ছেন। আপনি দেখতে পাচ্ছেন যে সাধারণ অঞ্চলে স্কুইডের স্মৃতির চাহিদা পূরণ করতে, কার্নেলটি সফলতা ছাড়াই 982 পৃষ্ঠা স্ক্যান করেছে:

pages_scanned:982 all_unreclaimable? yes
— ramruma
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.