Rsync সিঙ্গেল 50 জিবি ফাইলে লিনাক্স ওওএম ঘাতককে ট্রিগার করেছিল

66

আমার সার্ভার_এতে একটি 50 জিবি ফাইল রয়েছে এবং আমি এটি সার্ভার_বিতে অনুলিপি করছি। আমি দৌড়াই

server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file

সার্ভার_বিতে 2 গিগাবাইট সোয়াপ সহ 32 গিগাবাইট র‌্যাম রয়েছে। এটি বেশিরভাগ নিষ্ক্রিয় এবং প্রচুর ফ্রি র‍্যাম থাকা উচিত ছিল। এটিতে ডিস্কের প্রচুর জায়গা রয়েছে। প্রায় 32 গিগাবাইটে, দূরবর্তী পক্ষটি সংযোগটি বন্ধ করায় স্থানান্তর বাতিল হয়।

সার্ভার_বি এখন নেটওয়ার্কটি ছেড়ে দিয়েছে। আমরা ডেটা সেন্টারটিকে এটি পুনরায় চালু করতে বলি। ক্র্যাশ হওয়ার আগে যখন আমি কার্নেল লগটি দেখি তখন আমি দেখতে পাবো যে এটি 0 বাইট অদলবদল ব্যবহার করছে এবং প্রক্রিয়া তালিকাটি খুব কম মেমরি ব্যবহার করছে (আরএসসিএনসি প্রক্রিয়াটি র‌্যামের 600 কেবি ব্যবহার করে তালিকাভুক্ত করা হয়েছিল), তবে ওম_কিলারটি ছিল বুনো হয়ে যাচ্ছে এবং লগের সর্বশেষ জিনিসটি এটি মেটালগের কার্নেল রিডার প্রক্রিয়াটিকে হত্যা করে।

এটি কার্নেল 3.2.59, 32-বিট (সুতরাং কোনও প্রক্রিয়া যাইহোক 4 জিবি এর বেশি মানচিত্র করতে পারে না)।

এটি প্রায় যেন লিনাক্স দীর্ঘকালীন চলমান ডেমনগুলির চেয়ে ক্যাশিংকে বেশি প্রাধান্য দেয়। কি দেয়?? এবং আমি কীভাবে এটি আবার ঘটতে বাধা দেব?

এখানে oom_killer এর আউটপুট:

Sep 23 02:04:16 [kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0
Sep 23 02:04:16 [kernel] [1772321.850649] Pid: 21832, comm: clamd Tainted: G         C   3.2.59 #21
Sep 23 02:04:16 [kernel] [1772321.850651] Call Trace:
Sep 23 02:04:16 [kernel] [1772321.850659]  [<c01739ac>] ? dump_header+0x4d/0x160
Sep 23 02:04:16 [kernel] [1772321.850662]  [<c0173bf3>] ? oom_kill_process+0x2e/0x20e
Sep 23 02:04:16 [kernel] [1772321.850665]  [<c0173ff8>] ? out_of_memory+0x225/0x283
Sep 23 02:04:16 [kernel] [1772321.850668]  [<c0176438>] ? __alloc_pages_nodemask+0x446/0x4f4
Sep 23 02:04:16 [kernel] [1772321.850672]  [<c0126525>] ? pte_alloc_one+0x14/0x2f
Sep 23 02:04:16 [kernel] [1772321.850675]  [<c0185578>] ? __pte_alloc+0x16/0xc0
Sep 23 02:04:16 [kernel] [1772321.850678]  [<c0189e74>] ? vma_merge+0x18d/0x1cc
Sep 23 02:04:16 [kernel] [1772321.850681]  [<c01856fa>] ? handle_mm_fault+0xd8/0x15d
Sep 23 02:04:16 [kernel] [1772321.850685]  [<c012305a>] ? do_page_fault+0x20e/0x361
Sep 23 02:04:16 [kernel] [1772321.850688]  [<c018a9c4>] ? sys_mmap_pgoff+0xa2/0xc9
Sep 23 02:04:16 [kernel] [1772321.850690]  [<c0122e4c>] ? vmalloc_fault+0x237/0x237
Sep 23 02:04:16 [kernel] [1772321.850694]  [<c08ba7e6>] ? error_code+0x5a/0x60
Sep 23 02:04:16 [kernel] [1772321.850697]  [<c08b0000>] ? cpuid4_cache_lookup_regs+0x372/0x3b2
Sep 23 02:04:16 [kernel] [1772321.850700]  [<c0122e4c>] ? vmalloc_fault+0x237/0x237
Sep 23 02:04:16 [kernel] [1772321.850701] Mem-Info:
Sep 23 02:04:16 [kernel] [1772321.850703] DMA per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850704] CPU    0: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850706] CPU    1: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850707] CPU    2: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850709] CPU    3: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850711] CPU    4: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850713] CPU    5: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850714] CPU    6: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850716] CPU    7: hi:    0, btch:   1 usd:   0
Sep 23 02:04:16 [kernel] [1772321.850718] Normal per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850719] CPU    0: hi:  186, btch:  31 usd:  70
Sep 23 02:04:16 [kernel] [1772321.850721] CPU    1: hi:  186, btch:  31 usd: 116
Sep 23 02:04:16 [kernel] [1772321.850723] CPU    2: hi:  186, btch:  31 usd: 131
Sep 23 02:04:16 [kernel] [1772321.850724] CPU    3: hi:  186, btch:  31 usd:  76
Sep 23 02:04:16 [kernel] [1772321.850726] CPU    4: hi:  186, btch:  31 usd:  29
Sep 23 02:04:16 [kernel] [1772321.850728] CPU    5: hi:  186, btch:  31 usd:  61
Sep 23 02:04:16 [kernel] [1772321.850731] CPU    7: hi:  186, btch:  31 usd:  17
Sep 23 02:04:16 [kernel] [1772321.850733] HighMem per-cpu:
Sep 23 02:04:16 [kernel] [1772321.850734] CPU    0: hi:  186, btch:  31 usd:   2
Sep 23 02:04:16 [kernel] [1772321.850736] CPU    1: hi:  186, btch:  31 usd:  69
Sep 23 02:04:16 [kernel] [1772321.850738] CPU    2: hi:  186, btch:  31 usd:  25
Sep 23 02:04:16 [kernel] [1772321.850739] CPU    3: hi:  186, btch:  31 usd:  27
Sep 23 02:04:16 [kernel] [1772321.850741] CPU    4: hi:  186, btch:  31 usd:   7
Sep 23 02:04:16 [kernel] [1772321.850743] CPU    5: hi:  186, btch:  31 usd: 188
Sep 23 02:04:16 [kernel] [1772321.850744] CPU    6: hi:  186, btch:  31 usd:  25
Sep 23 02:04:16 [kernel] [1772321.850746] CPU    7: hi:  186, btch:  31 usd: 158
Sep 23 02:04:16 [kernel] [1772321.850750] active_anon:117913 inactive_anon:9942 isolated_anon:0
Sep 23 02:04:16 [kernel] [1772321.850751]  active_file:106466 inactive_file:7784521 isolated_file:0
Sep 23 02:04:16 [kernel] [1772321.850752]  unevictable:40 dirty:0 writeback:61 unstable:0
Sep 23 02:04:16 [kernel] [1772321.850753]  free:143494 slab_reclaimable:128312 slab_unreclaimable:4089
Sep 23 02:04:16 [kernel] [1772321.850754]  mapped:6706 shmem:308 pagetables:915 bounce:0
Sep 23 02:04:16 [kernel] [1772321.850759] DMA free:3624kB min:140kB low:172kB high:208kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolate
d(file):0kB present:15808kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:240kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tm
p:0kB pages_scanned:0 all_unreclaimable? yes
Sep 23 02:04:16 [kernel] [1772321.850763] lowmem_reserve[]: 0 869 32487 32487
Sep 23 02:04:16 [kernel] [1772321.850770] Normal free:8056kB min:8048kB low:10060kB high:12072kB active_anon:0kB inactive_anon:0kB active_file:248kB inactive_file:388kB unevictable:0kB isolated(anon)
:0kB isolated(file):0kB present:890008kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:513008kB slab_unreclaimable:16356kB kernel_stack:1888kB pagetables:3660kB unstable:0
kB bounce:0kB writeback_tmp:0kB pages_scanned:1015 all_unreclaimable? yes
Sep 23 02:04:16 [kernel] [1772321.850774] lowmem_reserve[]: 0 0 252949 252949
Sep 23 02:04:16 [kernel] [1772321.850785] lowmem_reserve[]: 0 0 0 0
Sep 23 02:04:16 [kernel] [1772321.850788] DMA: 0*4kB 7*8kB 3*16kB 6*32kB 4*64kB 6*128kB 5*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB = 3624kB
Sep 23 02:04:16 [kernel] [1772321.850795] Normal: 830*4kB 80*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 8056kB
Sep 23 02:04:16 [kernel] [1772321.850802] HighMem: 13*4kB 14*8kB 2*16kB 2*32kB 0*64kB 0*128kB 2*256kB 2*512kB 3*1024kB 0*2048kB 136*4096kB = 561924kB
Sep 23 02:04:16 [kernel] [1772321.850809] 7891360 total pagecache pages
Sep 23 02:04:16 [kernel] [1772321.850811] 0 pages in swap cache
Sep 23 02:04:16 [kernel] [1772321.850812] Swap cache stats: add 0, delete 0, find 0/0
Sep 23 02:04:16 [kernel] [1772321.850814] Free swap  = 1959892kB
Sep 23 02:04:16 [kernel] [1772321.850815] Total swap = 1959892kB
Sep 23 02:04:16 [kernel] [1772321.949081] 8650736 pages RAM
Sep 23 02:04:16 [kernel] [1772321.949084] 8422402 pages HighMem
Sep 23 02:04:16 [kernel] [1772321.949085] 349626 pages reserved
Sep 23 02:04:16 [kernel] [1772321.949086] 7885006 pages shared
Sep 23 02:04:16 [kernel] [1772321.949087] 316864 pages non-shared
Sep 23 02:04:16 [kernel] [1772321.949089] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
            (rest of process list omitted)
Sep 23 02:04:16 [kernel] [1772321.949656] [14579]     0 14579      579      171   5       0             0 rsync
Sep 23 02:04:16 [kernel] [1772321.949662] [14580]     0 14580      677      215   5       0             0 rsync
Sep 23 02:04:16 [kernel] [1772321.949669] [21832]   113 21832    42469    37403   0       0             0 clamd
Sep 23 02:04:16 [kernel] [1772321.949674] Out of memory: Kill process 21832 (clamd) score 4 or sacrifice child
Sep 23 02:04:16 [kernel] [1772321.949679] Killed process 21832 (clamd) total-vm:169876kB, anon-rss:146900kB, file-rss:2712kB

নন-রুট ব্যবহারকারী হিসাবে আমার rsync কমান্ডটি পুনরাবৃত্তি করার পরে এখানে 'শীর্ষ' আউটপুট রয়েছে:

top - 03:05:55 up  8:43,  2 users,  load average: 0.04, 0.08, 0.09
Tasks: 224 total,   1 running, 223 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0% us,  0.0% sy,  0.0% ni, 99.9% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:  33204440k total, 32688600k used,   515840k free,   108124k buffers
Swap:  1959892k total,        0k used,  1959892k free, 31648080k cached

এখানে সিসেক্টল ভিএম প্যারামিটারগুলি রয়েছে:

# sysctl -a | grep '^vm'
vm.overcommit_memory = 0
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.oom_dump_tasks = 1
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 1
vm.dirty_background_bytes = 0
vm.dirty_ratio = 0
vm.dirty_bytes = 15728640
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 60
vm.lowmem_reserve_ratio = 256   32      32
vm.drop_caches = 0
vm.min_free_kbytes = 8192
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.vdso_enabled = 2
vm.highmem_is_dirtyable = 0
vm.scan_unevictable_pages = 0
rsync  oom  oom-killer 
— dataless
সূত্র
2
আমি কার্নেল ক্র্যাশ বার্তা পড়তে কোনও বিশেষজ্ঞ নই, তবে আমি সেখানে কোনও ইঙ্গিত দেখতে পাচ্ছি না যে বি 32 জিবি কোর ব্যবহার করছে using এটি যে অনুমানের আগে আমরা এগিয়ে চলেছি, আপনি কি এটি বর্তমানে তা নিশ্চিত করতে পারবেন? কারণ 32GB কোর সহ একটি বাক্স মেমরি-ক্লান্ত করার মধ্যে এবং কেবল 4 জিবি সহ একটি বড় পার্থক্য রয়েছে।
— ম্যাডহ্যাটার
শীর্ষ আউটপুট সহ আপডেট হয়েছে। এটি একই আরএসআইএনসি-র কমান্ডটি অ-রুট ব্যবহারকারী হিসাবে চালানোর পরে। এখনই 1GB ব্যতীত সমস্ত কিছুই ক্যাশের জন্য ব্যবহৃত হয়।
— ডেটালেস
ধন্যবাদ। আমি যেমন বলেছি, আমি কোনও বিশেষজ্ঞ নই - তবে এটি চেক করার মতো বলে মনে হয়েছিল।
— ম্যাডহ্যাটার
আপনাকে এটিও যাচাই করা উচিত যে আপনার কার্নেলটি অদলবদল করতে দেয় (যেমন, সোয়াপিং বন্ধ নেই) (এবং আপনার ডিস্কের একটি বড় অংশ উত্সর্গ করা উচিত, আসুন 16 গিগাবাইট বা এমনকি 32 জিবি বলি)। নেটে কিছু অদ্ভুত ব্যক্তিরা অদলবদল বন্ধ করার পরামর্শ দেয়, এটি খুব ভুল।
— অলিভিয়ার ডুলাক
@ অলিভারডুলাক আপনি কোন সেটিংয়ের কথা উল্লেখ করছেন? অদলবদল সমর্থনটি সংকলিত আছে বা আমরা অদলবদল করতে সক্ষম হবো না, এবং 'অদলবদল' 60 এ সেট করা আছে sw উত্তরটি দেখা যাচ্ছে যে কার্নেলের ডেটা স্ট্রাকচারগুলিই আমাদের হত্যা করেছিল। আমরা 32 গিগাবাইট ব্যবহারকারীর প্রক্রিয়াগুলি চালাচ্ছি না, আমরা কেবল ডিস্ক ক্যাশে, পারফরম্যান্সের জন্য এতটা রাম চাই।
— ডেটালেস

উত্তর:

178

সুতরাং আসুন আমরা ওম-কিলার আউটপুট পড়ি এবং সেখান থেকে কী শিখতে পারে তা দেখুন।

OOM হত্যাকারী লগগুলি বিশ্লেষণ করার সময়, এটি কী কারণে ট্রিগার হয়েছিল তা লক্ষ্য করা গুরুত্বপূর্ণ। আপনার লগের প্রথম লাইনটি আমাদের কিছু ক্লু দেয়:

[কর্নেল] [1772321.850644] ক্ল্যামড আহ্বান করা ওম-কিলার: gfp_mask = 0x84d0, অর্ডার = 0

order=0কত স্মৃতি অনুরোধ করা হচ্ছে তা আমাদের জানাচ্ছে telling কার্নেলের মেমরি পরিচালনাটি কেবলমাত্র 2 নম্বরগুলিতে পৃষ্ঠা সংখ্যা পরিচালনা করতে সক্ষম, সুতরাং ক্ল্যামড 2 0 পৃষ্ঠার মেমরি বা 4KB অনুরোধ করেছে ।

GFP_MASK এর সর্বনিম্ন দুটি বিট (ফ্রি পৃষ্ঠার মুখোশ পান) বরাদ্দকারীকে কোন অঞ্চল থেকে স্মৃতি পেতে হবে তা বলে তথাকথিত অঞ্চল মুখোশ গঠন করে :

Flag            value      Description
                0x00u      0 implicitly means allocate from ZONE_NORMAL
__GFP_DMA       0x01u      Allocate from ZONE_DMA if possible
__GFP_HIGHMEM   0x02u      Allocate from ZONE_HIGHMEM if possible

মেমরি অঞ্চলগুলি মূলত সামঞ্জস্যের কারণে তৈরি একটি ধারণা। সরলীকৃত দৃষ্টিতে একটি x86 কার্নেলের জন্য তিনটি অঞ্চল রয়েছে:

Memory range   Zone       Purpose 

0-16 MB        DMA        Hardware compatibility (devices)
16 - 896 MB    NORMAL     space directly addressable by the Kernel, userland 
> 896 MB       HIGHMEM    userland, space addressable by the Kernel via kmap() calls

আপনার ক্ষেত্রে, জোনমাস্কটি 0, যার অর্থ ক্ল্যামড মেমোরির জন্য অনুরোধ করছে ZONE_NORMAL।

অন্যান্য পতাকাগুলি সমাধান হচ্ছে

/*
 * Action modifiers - doesn't change the zoning
 *
 * __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt
 * _might_ fail.  This depends upon the particular VM implementation.
 *
 * __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
 * cannot handle allocation failures.
 *
 * __GFP_NORETRY: The VM implementation must not retry indefinitely.
 */
#define __GFP_WAIT      0x10u   /* Can wait and reschedule? */
#define __GFP_HIGH      0x20u   /* Should access emergency pools? */
#define __GFP_IO        0x40u   /* Can start physical IO? */
#define __GFP_FS        0x80u   /* Can call down to low-level FS? */
#define __GFP_COLD      0x100u  /* Cache-cold page required */
#define __GFP_NOWARN    0x200u  /* Suppress page allocation failure warning */
#define __GFP_REPEAT    0x400u  /* Retry the allocation.  Might fail */
#define __GFP_NOFAIL    0x800u  /* Retry for ever.  Cannot fail */
#define __GFP_NORETRY   0x1000u /* Do not retry.  Might fail */
#define __GFP_NO_GROW   0x2000u /* Slab internal usage */
#define __GFP_COMP      0x4000u /* Add compound page metadata */
#define __GFP_ZERO      0x8000u /* Return zeroed page on success */
#define __GFP_NOMEMALLOC 0x10000u /* Don't use emergency reserves */
#define __GFP_NORECLAIM  0x20000u /* No realy zone reclaim during allocation */

অনুযায়ী লিনাক্স এমএম ডকুমেন্টেশন , তাই আপনার requst পতাকা জন্য গেছে GFP_ZERO, GFP_REPEAT, GFP_FS, GFP_IOএবং GFP_WAITএইভাবে বিশেষ করে খুঁতখুঁতে হচ্ছে না।

তাহলে কি হবে ZONE_NORMAL? কিছু জেনেরিক পরিসংখ্যান OOM আউটপুটে আরও পাওয়া যাবে:

[কর্নেল] [1772321.850770] সাধারণ বিনামূল্যে: 8056 কেবি মিনিট: 8048 কেবি নিম্ন: 10060 কেবি উচ্চ: 12072 কেবি সক্রিয়_নোন: 0 কেবি নিষ্ক্রিয়_নোন: 0 কেবি অ্যাক্টিভ_ফাইল: 248 কেবি নিষ্ক্রিয়_ফায়াল: 388 কেবি অবাস্তব: 0 কেবি বিযুক্ত: 0000 বি: 0 কেবি (ফাইল): 0 কেবি: 0000 বিবি: 0 কেবি আইসো: 0000 বিবি

এখানে লক্ষণীয় যে freeএটি কেবল 8K থেকে minএবং এর নীচে low। এর অর্থ হল আপনার হোস্টের মেমরির পরিচালকটি কিছুটা সঙ্কটে রয়েছে এবং নীচের গ্রাফের হলুদ পর্যায়ে যেমন ইতিমধ্যে পৃষ্ঠাগুলি অদলবদল করা উচিত, তেমন গুপ্তচরবৃত্তি করা উচিত : লিনাক্স মেমরি ম্যানেজার গ্রাফ

জোনের মেমরি বিভাজন সম্পর্কে আরও কিছু তথ্য এখানে দেওয়া হল:

[কর্নেল] [1772321.850795] সাধারণ: 830 * 4 কেবি 80 * 8 কেবি 0 * 16 কেবি 0 * 32 কেবি 0 * 64 কেবি 0 * 128 কেবি 0 * 256 কেবি 0 * 512 কেবি 0 * 1024 কেবি 0 * 2048 কেবি 1 * 4096 কেবি = 8056 কেবি

মূলত উল্লেখ করে যে আপনার 4MB এর একটি একক সঙ্গতিপূর্ণ পৃষ্ঠা রয়েছে বাকী অংশটি মূলত 4KB পৃষ্ঠাগুলিতে বিভক্ত।

সুতরাং আসুন পুনরুক্তি করা যাক:

  • আপনার একটি ইউজারল্যান্ড প্রক্রিয়া ( clamd) মেমরি পেয়েছে ZONE_NORMALসেহেতু অ-সুবিধাপ্রাপ্ত মেমরির বরাদ্দ সাধারণত করা হয়ZONE_HIMEM
  • মেমরি পরিচালকের উচিত এই পর্যায়ে অনুরোধ করা 4K পৃষ্ঠা পরিবেশন করতে সক্ষম হওয়া উচিত, যদিও আপনার মনে হয় এর মধ্যে উল্লেখযোগ্য মেমরি চাপ রয়েছে pressure ZONE_NORMAL
  • সিস্টেমের kswapdনিয়ম অনুসারে, কিছু আগে থেকেই কিছু পেজিং ক্রিয়াকলাপ দেখে নেওয়া উচিত ছিল, তবে কোনও কিছুই অদলবদল হচ্ছে না, এমনকি মেমরির চাপের মধ্যেও ZONE_NORMAL, আপাত কারণ ছাড়াই
  • উপরোক্তগুলির মধ্যে oom-killerকোনওটি কেন প্রার্থনা করা হয়নি তার একটি নির্দিষ্ট কারণ দেয় না

এগুলি সমস্তই অদ্ভুত বলে মনে হয় তবে জন ও'গরম্যানের দুর্দান্ত "লিনাক্স ভার্চুয়াল মেমরি ম্যানেজার বোঝার" বইয়ের অধ্যায় 2.5 তে বর্ণিত বর্ণনার সাথে সম্পর্কিত হতে পারে :

কার্নেলের (ZONE_NORMAL) দ্বারা ব্যবহারযোগ্য ঠিকানাগুলির স্থানটি আকারে সীমিত হওয়ায় উচ্চ মেমোরির ধারণার জন্য কার্নেলের সমর্থন রয়েছে। [...] 1GiB এবং 4GiB এর পরিসরের মধ্যে মেমোরি অ্যাক্সেস করতে, কার্নেল অস্থায়ীভাবে হাই মেমরি থেকে KMAP () দিয়ে ZONE_NORMAL এ পৃষ্ঠাগুলি ম্যাপ করে। [...]

এর অর্থ হ'ল 1GiB মেমরির বর্ণনা দিতে, প্রায় 11MiB কার্নেল মেমরি প্রয়োজন। সুতরাং, 16 জিআইবি সহ, 176 মিমি মেমরি গ্রাস করা হয়, এটি ZONE_NORMAL এর উপর উল্লেখযোগ্য চাপ দেয়। অন্যান্য কাঠামোগুলি বিবেচনায় না নেওয়া পর্যন্ত এটি খুব খারাপ শোনাবে না যা ZONE_NORMAL ব্যবহার করে। এমনকি পেজ টেবিল এন্ট্রিগুলির (পিটিই) মতো খুব ছোট কাঠামোর জন্য সবচেয়ে খারাপ ক্ষেত্রে প্রায় 16MiB প্রয়োজন। এটি একটি x86-তে উপলব্ধ শারীরিক মেমরি লিনাক্সের ব্যবহারিক সীমা সম্পর্কে 16GiB করে ।

(জোর আমার)

যেহেতু ৩.২ এর ২.6-র বেশি মেমরি পরিচালনায় রয়েছে অনেকগুলি অগ্রগতি, এটি একটি নির্দিষ্ট উত্তর নয়, তবে সত্যিই শক্তিশালী ইঙ্গিতটি আমি প্রথমে অনুসরণ করব। হয় mem=কার্নেল প্যারামিটার ব্যবহার করে বা সার্ভারের বাইরে অর্ধেক ডিআইএমএম ছিড়ে করে হোস্টের ব্যবহারযোগ্য মেমরিটিকে কমপক্ষে 16G এ হ্রাস করুন ।

শেষ পর্যন্ত, একটি -৪-বিট কার্নেল ব্যবহার করুন ।

বাবু, এটা 2015।

— -wabbit
সূত্র
13
যখন আমি উপরে বলেন, " আমি কোন বিশেষজ্ঞ ", এই কি আমি পড়েছি প্রত্যাশী হয়। +1000, যদি আমি পারতাম; অবশ্যই +1। কি দুর্দান্ত উত্তর!
— ম্যাডহ্যাটার
18
ওটা সুন্দর ছিল. এসএফের জন্য এখনও আশা আছে।
— রোমান
9
@ ডেটালেস হ্যাঁ আমি সন্দেহ করি যে আপনার সমস্ত ZONE_NORMAL উপরের স্মৃতি অঞ্চলগুলি সম্পর্কে মেটাডেটাতে পূর্ণ filled যখন কোনও ইউজারল্যান্ড প্রক্রিয়া মেমরি পৃষ্ঠাগুলির জন্য অনুরোধ করছে, সম্ভবত এটি ZONE_HIGHMEM (যা এমএম দ্বারা ZONE_NORMAL এ আপগ্রেড করা হতে পারে যদি উচ্চতর অনুরোধটি পরিবেশন করার জন্য আরও বিনামূল্যে পৃষ্ঠাগুলি না থাকলেও সাধারণ রয়েছে), সুতরাং ZONE_HIGHMEM মেমরির চাপে না থাকলে (আপনার নয়), ZONE_NORMAL এর কোনও ব্যবহারকারী-স্থান প্রক্রিয়াগুলির পৃষ্ঠা থাকবে না।
— দ্য ওয়াবিট
3
[কীবোর্ডে মুগ্ধতার ঝাঁকুনি] এই ওয়াবটটিকে অনুগ্রহটি দিন
— আন্ডারস্কোর_ডে
3
@ দ্য ওয়াববিট হট নেটওয়ার্ক প্রশ্নগুলি।
— কোডসইনচাউস
4

কিছু জিনিস ...

অদলবদলের জায়গার জন্য আমার নিয়মের থাম্বের দৈহিক র‌্যামের পরিমাণ কমপক্ষে 2x হওয়া উচিত। এটি পৃষ্ঠা / অদলবদলের ডিমনকে মেমরির দক্ষতার সাথে পুনরায় সাজানোর ক্ষমতা দেয়।

সার্ভার_বিতে 32 গিগাবাইট র‌্যাম রয়েছে, তাই এটি 64 গিগাবাইট স্বাপের জন্য কনফিগার করার চেষ্টা করুন। আইএমও, swap 'র স্থান 2GB আপনার সার্ভারে আছে উপায় বিশেষ করে একটি সার্ভারের জন্য খুব কম।

আপনার যদি কোনও অতিরিক্ত পার্টিশন না থাকে যা আপনি স্যুপ পার্টিশনে তৈরি করতে পারেন তবে আপনি এটি ফাইল তৈরি করে এটিকে স্ব্যাপ পার্টিশন হিসাবে মাউন্ট করে পরীক্ষা করতে পারেন [এটি ধীর হয়ে যাবে]। Https://www.maketecheasier.com/swap-partitions-on-linux/ দেখুন

যেহেতু সার্ভার_বিতে প্রচুর ডিস্কের স্থান রয়েছে, --inplus প্রয়োজন হয় না এবং এটি অনাকাঙ্ক্ষিত হতে পারে কারণ এটিই হতে পারে রিসাইএনসি 32 জিবি ব্যবহার করতে পারে। --inplace কেবলমাত্র তখনই কার্যকর যদি আপনি ফাইল সিস্টেমের জায়গাতে [যা আপনি নন] বা আপনার কিছু বিশেষ পারফরম্যান্সের প্রয়োজনীয়তা কম থাকে short

আমার অনুমান যে আরএসসিএনসি আপনার বর্তমান বিকল্পগুলির সাথে 50 গিগাবাইট র্যাম [ফাইলের আকার] ব্যবহার করতে চাইবে। সাধারণত, rsync এর কাজটি করার জন্য তেমন মেমরির প্রয়োজন হয় না, তাই আপনার এক বা একাধিক বিকল্পের সমস্যা হতে পারে। আমি নিয়মিত কোনও সমস্যা ছাড়াই 200GB ফাইল স্থানান্তর করি transfer

কোনও বিকল্প ব্যবহার করে কিছু পরীক্ষা চালায়। ছোট ফাইল দিয়ে এটি করুন, 10 গিগা বলুন - এটি কার্নেল আতঙ্ককে আটকাতে পারে তবে তবুও আপনাকে এমন সমস্যার আচরণ পর্যবেক্ষণ করতে দেয় যা সমস্যা সৃষ্টি করে। আরএসএনসি-র মেমরির ব্যবহার নিরীক্ষণ করুন।

ধীরে ধীরে, একবারে বিকল্পগুলি যুক্ত করুন, কোন বিকল্পে [বা বিকল্পগুলির সংমিশ্রণটি] দেখতে রাইসে পিগিং আউট শুরু করার জন্য আরএসইএনসি সৃষ্টি করে (উদাহরণস্বরূপ ট্রান্সফারটি ঘটছে, আরএসসিএনএইএম এর র‌্যামের পরিমাণ আনুপাতিকভাবে স্থানান্তরিত ফাইল ডেটার পরিমাণের সাথে বাড়বে, ইত্যাদি)।

যদি আপনার সত্যিকারের এমন বিকল্পগুলির প্রয়োজন হয় যেগুলির ফলে কিছুটা ইন-রাম ফাইল চিত্র রাখার জন্য rsync তৈরি হয় তবে আপনার অতিরিক্ত অদলবদল স্থান প্রয়োজন এবং সেই অনুযায়ী আপনার সর্বাধিক ফাইলের আকার সীমাবদ্ধ থাকবে।

আরও কয়েকটি জিনিস [আপডেট করা]:

(1) কার্নেল স্ট্যাকের ট্রেসব্যাকটি দেখায় যে এমএসএপ অঞ্চলে আরএসইএনসি পৃষ্ঠাটি ত্রুটিযুক্ত ছিল। এটি সম্ভবত ফাইলটি ম্যামপিং করছে। এমএমএপি কোনও গ্যারান্টি দেয় না যে ফাইলটি বন্ধ না হওয়া অবধি এটি ডিস্কে ফ্লাশ হয়ে যাবে [পড়ুন / লেখার বিপরীতে] যা এখনই এফএস ব্লক ক্যাশে যায় [যেখানে এটি ফ্লাশ করা হবে]

(২) ট্রান্সফার আকারটি র‌্যামের আকারকে আঘাত করলে কার্নেল ক্রাশ / আতঙ্ক দেখা দেয়। স্পষ্টতই rsync ম্যালোক বা এমএম্যাপের মাধ্যমে সেই নন-এফস্কেচ মেমোরিটিকে দখল করছে। আবার, আপনার নির্দিষ্ট করা বিকল্পগুলির সাথে, আরএসআইএনসি একটি 50 জিবি ফাইল স্থানান্তর করতে 50 গিগাবাইট মেমরি বরাদ্দ করবে।

(3) একটি 24 জিবি ফাইল স্থানান্তর করুন। সম্ভবত এটি কাজ করবে। তারপরে, mem = 16G দিয়ে কার্নেলটি বুট করুন এবং আবার 24GB ফাইল পরীক্ষা করুন। এটি 32 গিগাবাইটের চেয়ে 16 গিগাবাইটে ফুরিয়ে যাবে। এটি নিশ্চিত করবে যে রিসাইক আসলেই মেমরির প্রয়োজন।

(৪) অদলবদল যোগ করা হাস্যকর বলে বলার আগে, কিছু কিছু যুক্ত করার চেষ্টা করুন [সোয়াপ-টু-ফাইল পদ্ধতির মাধ্যমে]। কীভাবে অদলবদলের প্রয়োজন হয় না সে সম্পর্কে সমস্ত একাডেমিক যুক্তির চেয়ে এটি করা এবং পরীক্ষা করা অনেক সহজ। এমনকি যদি এটি সমাধান না হয় তবে আপনি এটি থেকে কিছু শিখতে পারেন। আমি বাজি ধরব যে মেম = 16 জি পরীক্ষা কোনও আতঙ্ক / ক্রাশ ছাড়াই সফল হবে।

(৫) সম্ভাবনা হ'ল আরএসইএনসি অদলবদল করছে, তবে ওওএম আরএসসিএনকে কিক করে মেরে ফেলার আগে এটি শীর্ষে দেখতে খুব দ্রুত ঘটে। আরএসসিএনসি 32 গিগাবাইটে পৌঁছে যাওয়ার পরে, অন্যান্য প্রক্রিয়াগুলি ইতিমধ্যে অদলবদল করতে বাধ্য হয়েছে, বিশেষত যদি তারা অলস থাকে। সম্ভবত, "ফ্রি" এবং "শীর্ষ" এর সংমিশ্রণ আপনাকে আরও ভাল চিত্র দেবে।

()) আরএসসিএনসি মারা যাওয়ার পরে, এমএসএপ এফএসে ফ্লাশ করতে সময় লাগে। OOM এর পক্ষে পর্যাপ্ত দ্রুত নয় এবং এটি অন্যান্য জিনিসকে হত্যা করা শুরু করে [কিছু স্পষ্টতই মিশন সমালোচনামূলক]। অর্থাৎ এমএমএপ ফ্লাশ এবং ওওএম রেস করছে। অথবা, ওওমের একটি বাগ রয়েছে। অন্যথায়, একটি ক্রাশ হবে না।

()) আমার অভিজ্ঞতা অনুসারে, একবার কোনও সিস্টেম "স্মৃতি প্রাচীরকে আঘাত করে", লিনাক্স পুরোপুরি পুনরুদ্ধারে দীর্ঘ সময় নেয়। এবং, কখনও কখনও এটি সত্যিকার অর্থে পুনরুদ্ধার হয় না এবং এটি পরিষ্কার করার একমাত্র উপায় হ'ল রিবুট। উদাহরণস্বরূপ, আমার 12 জিবি র‌্যাম রয়েছে have আমি যখন 40GB গিগাবাইট মেমরি ব্যবহার করে এমন একটি চাকরি চালিয়ে যাই [আমার কাছে বড় চাকরির সামঞ্জস্য আনতে 120 গিগাবাইট সোয়াপ রয়েছে] এবং তারপরে এটি হত্যা করি, তখন সিস্টেমটিকে স্বাভাবিক প্রতিক্রিয়াতে ফিরে আসতে প্রায় 10 মিনিট সময় লাগে [যখন ডিস্কের আলো শক্ত হয়ে থাকে] ।

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

দ্বিতীয় আপডেট:

উপরের থেকে দয়া করে মেমো = এবং আরও ছোট ফাইল পরীক্ষা করুন।

কেন্দ্রীয় প্রশ্ন: আরএসইএনসি কেন ওম দ্বারা নিহত হয়? কে / কী স্মরণ করিয়ে দিচ্ছে?

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

একটি দ্রুত লুপে পার্ল বা পাইথন স্ক্রিপ্টের মাধ্যমে আপনি / proc বা / proc / rsync_pid এ নজর রাখতে পারেন এমন কিছু জিনিস [দ্য ওয়ার্ল্ড ইভেন্টটি দ্য ওয়ার্ল্ড ইভেন্টের জন্য সম্ভবত যথেষ্ট পর্যাপ্ত হবে না] যা সমস্ত পর্যবেক্ষণ করতে পারে নিম্নলিখিত কয়েকশ বার / সেকেন্ড আপনি এটি আরএসইএনসি-র তুলনায় উচ্চতর অগ্রাধিকারে চালাতে পারেন তাই এটি নিজেকে র‌্যামে রাখে এবং চলতে থাকবে যাতে আপনি ক্রাশের ঠিক আগে জিনিসগুলি পর্যবেক্ষণ করতে পারেন এবং আশা করা যায় যে ওওম পাগল হয় কেন আপনি দেখতে পারেন:

/ proc / meminfo - "প্রভাবের স্থানে" অদলবদলের ব্যবহারের জন্য আরও সূক্ষ্ম শস্য প্রাপ্ত করতে। আসলে, মোট কতটা র‌্যাম ব্যবহার হচ্ছে তার চূড়ান্ত নম্বর পাওয়া আরও কার্যকর হতে পারে। শীর্ষস্থানীয় এটি সরবরাহ করার পরে, "বিগ ব্যাং" এর আগে মহাবিশ্বের অবস্থা প্রদর্শন করার পক্ষে এটি দ্রুত পর্যাপ্ত নাও হতে পারে (উদাহরণস্বরূপ সর্বশেষ 10 মিলিসেকেন্ড)

/ proc / rsync_pid / fd ডিরেক্টরি। সিমলিংকগুলি পড়া আপনাকে লক্ষ্য ফাইলটিতে কোন এফডি খোলার তা সনাক্ত করতে দেয় (উদাহরণস্বরূপ / proc / rsync_pid / fd / 5 -> টার্গেট_ফাইলে পড়ুন)। এফডি নম্বর পাওয়ার জন্য এটি কেবল একবার করা দরকার [এটি স্থির থাকা উচিত]

এফডি নম্বর জানার জন্য / proc / rsync_pid / fdinfo / fd দেখুন। এটি এমন একটি টেক্সট ফাইল যা দেখে মনে হচ্ছে:

পোস্ট: <ফাইল / অবস্থান>
পতাকা: blah_blah
mnt_id: bla_blah

"সর্বশেষ ফাইলের অবস্থান" কার্যকর হতে পারে বলে "পোস্ট" মান পর্যবেক্ষণ করা সহায়ক হতে পারে। আপনি যদি বিভিন্ন আকার এবং মেম = বিকল্পগুলি সহ বেশ কয়েকটি পরীক্ষা করে থাকেন তবে শেষ ফাইলের অবস্থানটি এইগুলির [এবং কীভাবে] ট্র্যাক করে? স্বাভাবিক সন্দেহযুক্ত: ফাইলের অবস্থান == উপলব্ধ র‍্যাম

তবে, সবচেয়ে সহজ উপায় হ'ল "rsync লোকাল_ফায়াল সার্ভার: রিমোট_ফায়াল" দিয়ে শুরু করা এবং যা কাজ করে তা যাচাই করে। আপনি "ssh সার্ভার আরএসএনসি ফাইল_এ ফাইল_বি" করে একই জাতীয় [তবে দ্রুত] ফলাফল পেতে সক্ষম হতে পারেন [আপনাকে প্রথমে একটি 50 জিবি ফাইল_এ তৈরি করতে হবে]। ফাইল_এ তৈরির একটি সহজ উপায় হ'ল স্ক্রিপ লোকাল_সিস্টেম: আসল_ফায়াল সার্ভার: ফাইল_এ এবং এটি নিজের জন্য আকর্ষণীয় হতে পারে (উদাহরণস্বরূপ, এই কাজটি যখন আরএসসিএনসি ক্র্যাশ হয় তখন? যদি স্ক্রিপ কাজ করে তবে আরএসসিএনএই ব্যর্থ হয়, এই পয়েন্টটি আরএসসিএনসি-র কাছে ব্যর্থ হয়, যদি স্ক্রিপ ব্যর্থ হয় তবে এই পয়েন্টগুলি এনআইসি ড্রাইভারের মতো অন্য কিছুতে)। Ssh rsync করা সমীকরণের বাইরে এনআইসিও বের করে, যা সহায়ক হতে পারে। যদি এটি সিস্টেমে পরাজিত হয় তবে কিছু সত্যিই ভুল। যদি এটি সফল হয়, [যেমন আমি উল্লেখ করেছি] একের পর এক বিকল্পগুলি যুক্ত করতে শুরু করুন।

আমি বিন্দুটি বেলবোর করতে পছন্দ করি না, তবে সোয়াপ-টু-ফাইলের মাধ্যমে কিছু অদলবদল ক্র্যাশ আচরণটি পরিবর্তন / বিলম্ব করতে পারে এবং ডায়াগনস্টিক সরঞ্জাম হিসাবে কার্যকর হতে পারে। যদি 16 গিগাবাইট বলুন, অদলবদলটি 32 গিগাবাইট থেকে 46 গিগাবাইটে [মেমরির ব্যবহার বা টার্গেট ফাইলের অবস্থান অনুসারে] ক্র্যাশকে বিলম্বিত করে, তবে এটি কিছু বলবে।

এটি কোনও বিশেষ প্রক্রিয়া নাও হতে পারে, তবে স্মরণ চিবানো একটি ত্রুটিযুক্ত কার্নেল ড্রাইভার। কার্নেলের অভ্যন্তরীণ ভিমলোক স্টাফ বরাদ্দ করে এবং এটি সরিয়ে নেওয়া যায়। আইআইআরসি, এটি সমস্ত পরিস্থিতিতে ঠিকানার দ্বারা আবদ্ধ নয়।

স্পষ্টতই, OOM বিভ্রান্ত / আতঙ্কিত হয়ে উঠছে। এটি, আরএসসিএনকে মেরে ফেলে, তবে স্মৃতিটি সময়মতো মুক্তি দেয় না এবং অন্যান্য ক্ষতিগ্রস্থদের সন্ধান করে। তাদের মধ্যে কিছু সম্ভবত সিস্টেম অপারেশনের জন্য গুরুত্বপূর্ণ।

malloc / mmap একসাথে রেখে ফালু এফএস ক্যাশে হতে পারে যা দীর্ঘ সময় নেয় (উদাহরণস্বরূপ, 30 গিগাবাইট অবহিত ডেটা সহ 300 এমবি / সেকেন্ডের ডিস্ক রেট ধরে, এটি ফ্লাশ করতে 100 সেকেন্ড সময় লাগতে পারে)। এমনকি সেই হারেও ওওএম খুব অধৈর্য হতে পারে। অথবা, OOM হত্যার আরএসসিএনসি যথেষ্ট দ্রুত এফএস ফ্লাশ শুরু করে না [বা একেবারে]। বা এফএস ফ্লাশটি দ্রুত পর্যাপ্ত ঘটে, তবে এতে পৃষ্ঠাগুলি ফ্রি পুলে ফিরে আসে "অলস"। এফএস ক্যাশে আচরণ নিয়ন্ত্রণ করতে আপনি সেট করতে পারেন এমন কয়েকটি / প্রোক বিকল্প রয়েছে [সেগুলি কী তা আমি মনে করতে পারি না]।

মেম = 4 জি বা অন্য কোনও ছোট সংখ্যার সাহায্যে বুট করার চেষ্টা করুন। এটি এফএস ক্যাশেটি কেটে ফেলতে পারে এবং ওওএমকে হত্যা করার জন্য অন্যান্য জিনিসগুলির সন্ধান থেকে বিরত রাখার জন্য এর ফ্লাশ সময়টি কমিয়ে দেয় (যেমন ফ্লাশের সময়টি 100 সেকেন্ড থেকে <1 সেকেন্ডে হ্রাস করা হয়)। এটি একটি ওওএম বাগটিও আনমাস্ক করতে পারে যা 32 বিট সিস্টেমে বা এ জাতীয় কিছুতে শারীরিক র‌্যাম> 4 জিবি পরিচালনা করতে পারে না।

এছাড়াও, একটি গুরুত্বপূর্ণ বিষয়: নন-রুট হিসাবে চালান। রুট ব্যবহারকারীদের কখনই সম্পদ চিবানো আশা করা হয় না, তাই তাদেরকে আরও ক্ষমা করার সীমা দেওয়া হয় (উদাহরণস্বরূপ 99% মেমরি বনাম 95% নন-রুট ব্যবহারকারীদের জন্য)। এটি OOM কেন এমন অবস্থায় রয়েছে তা ব্যাখ্যা করতে পারে। এছাড়াও, এটি OOM এট দেয়। অল। মেমরি পুনরুদ্ধারের কাজটি করার জন্য আরও প্রধান কক্ষ।

— ক্রেগ এস্টে
সূত্র
একটি উচ্চ মেমরি সিস্টেমে কতটা সুইট স্পেস দেখুন ? - এবং আপনি আপনার সিস্টেমটি GB৩ গিগাবাইটের অদলবদল দেখতে চান না। এটি ব্যবহারযোগ্য হবে না।
— মার্টিন শ্র্রেডার
1
অদলবদল> র‌্যাম কেবলমাত্র তখনই কার্যকর যদি আপনি ভিএম ওভারকমিট ছাড়াই চালান, সুতরাং কার্নেলকে বরাদ্দকৃত পৃষ্ঠাগুলির জন্য অদলবদল হওয়া পর্যন্ত স্বাপের স্থান সংরক্ষণ করা দরকার এবং সেগুলি সমর্থন করার জন্য প্রকৃত শারীরিক পৃষ্ঠাগুলির প্রয়োজন হয় না। বর্তমান অনুশীলনটি হ'ল ওভার কমিটকে অনুমতি দেওয়া এবং স্বল্প পরিমাণে অদলবদল পাতায় পৃষ্ঠাগুলি চালানো যেগুলি কেবল প্রারম্ভকালে স্পর্শ করা হয়েছিল এবং সাধারণ ক্রিয়াকলাপে প্রয়োজনীয় নয়। বেশিরভাগ সিস্টেমে আপনার কাছে প্রচুর র‍্যাম থাকলে ছোট স্বাপের সাথে ওভারকমিট = 0 ঠিক আছে।
— পিটার কর্ডেস
মনে হচ্ছে rsync সত্যিই হয় ব্যবহার করতে> 32GB চেষ্টা, তাই সোয়াপ যে জন্য প্রয়োজন হয়। অর্থাৎ, আরএসসিএনসি এই ফাইলটির জন্য 50 গিগাবাইট ব্যবহার করতে চলেছে। 2x 30 বছর ধরে একটি চেষ্টা করা হয়েছে এবং সত্য মেট্রিক। যেহেতু 6TB ডিস্কটি 300 ডলার, তাই না করার কোনও কারণ নেই। এই সার্ভারে আর কী চলতে পারে যা সম্মিলিতভাবে র‌্যাম সীমাটি সরিয়ে ফেলবে?
— ক্রেগ এস্তে
1
@ ক্রেইগস্টেটি GB৪ গিগাবাইট অদলবদল সম্পূর্ণ হাস্যকর কারণ যেহেতু আমি আগেই বলেছি যে আমাদের কাছে বড় ব্যবহারকারীর প্রসেস নেই, আমরা কেবল ডিস্কের ক্যাশে চাই এবং আমার লগটি যেমন দেখায়, ক্র্যাশ হওয়ার সময় আমরা জিরো অদলবদ ব্যবহার করছিলাম। শূন্য। এছাড়াও rsync এমনকি একটি 50 গিগাবাইট ফাইলে 600KB র‌্যাম ব্যবহার করে। আমার প্রাথমিক বিভ্রান্তিটি হ'ল সম্ভবত লিনাক্স আগ্রাসীভাবে ডিস্ক ক্যাশে চেপে ধরেছিল। এবং অবশেষে, আমি এই বাক্সে আরও কোনও যুক্ত করার আগে কার্নেলটি তার অদলবদল স্থানটি ট্র্যাক করতে কত মেমরি ব্যবহার করে সে সম্পর্কে কিছু নম্বর বা ডকুমেন্টেশন দেখতে চাই।
— ডেটালেস
@ ডেটালেস আমি অতিরিক্ত তথ্য যুক্ত করেছি যা কী ঘটছে এবং কেন তা পুরোপুরি ব্যাখ্যা করে। rsync হয় যদি malloc / mmap মাধ্যমে মেমরি দখল এবং এটি 50GB জন্য আগেই সম্পন্ন যেতে হবে। আপডেট বিভাগ দেখুন। এটিতে এমন পরীক্ষাগুলি রয়েছে যা আমি যা বলছি তা প্রমাণ / প্রমাণ করতে পারে এবং পরীক্ষার জন্য আপনি প্রাথমিকভাবে অ্যাড সোয়েপটি এড়িয়ে যেতে পারেন। বিটিডাব্লু, আমি 40+ বছর ধরে কার্নেল / ড্রাইভার প্রোগ্রামিং করছি - আমি কেবল এমন কিছু জানতে পারি যা আপনি জানেন না, তাই দয়া করে সুরটি সংযত করুন - আমি সাহায্য করার চেষ্টা করছি ।
— ক্রেগ এস্তে
2

clamd? মনে হচ্ছে আপনি ক্ল্যামএভি ব্যবহার করছেন এবং অ্যান-অ্যাক্সেস স্ক্যানিং সক্ষম করেছেন যেখানে অ্যান্টি-ভাইরাস ইঞ্জিন মেমরিতে লোড করে, অন্য কোনও প্রক্রিয়া দ্বারা খোলার প্রতিটি ফাইলের পুরো বিষয়বস্তুতে ভাইরাসগুলির জন্য খোলা ফাইলগুলি স্ক্যান করার চেষ্টা করে ।

আপনার সুরক্ষা ভঙ্গি এবং এই স্থানান্তরটির প্রয়োজনীয়তার উপর নির্ভর করে, আপনি স্থানান্তরটি সম্পাদন করার সময় আপনার ক্ল্যামাভি অন-অ্যাক্সেস স্ক্যানিং অক্ষম করার মূল্যায়ন করতে হবে।

— ওও।
সূত্র
আমি সচেতন ছিলাম না এটি এমনকি দাবিদার কাজটি করতে পারে এমন একটি জিনিস ছিল ... তবে আমরা কেবল ক্ল্যামক থেকে পাইপযুক্ত নির্দিষ্ট ফাইলগুলি স্ক্যান করি না। এছাড়াও, 32-বিট, তাই সমস্ত সিস্টেমের মেমরিকে জড়িয়ে থাকা ক্ল্যামাভের কোনও বিপদ নেই। (আপনি দেখুন কেন আমরা 32-বিটটি এখনও একটি ভাল ধারণা বলে মনে করেছি?)
— ডেটালেস
1
লিনাক্স কার্নেল জানিয়েছে যে ক্ল্যামড হ'ল প্রক্রিয়া যার মেমরি বরাদ্দকরণের অনুরোধগুলি OOM হত্যাকারীকে আহ্বান করছে - ক্ল্যামাভি প্রায় অবশ্যই দ্বিতীয় কারণ (প্রাথমিক কারণ পর্যাপ্ত মেমরি নয়)। এটি অন-অ্যাক্সেস স্ক্যানিং বা অন্য কোনও কনফিগারেশন হোক না কেন, সমস্ত লক্ষণ ক্ল্যামাভিতে নির্দেশ করে।
— ওও
পরের বার আপনি আরএসসিএনসি শুরু করুন, শীর্ষে রান করুন এবং ক্ল্যামড প্রক্রিয়াটির আবাসিক আকারটি নিরীক্ষণ করুন।
— ওও
ক্ল্যামড হ'ল ওম কিলারকে আক্রমন করার প্রথম প্রক্রিয়া, তবে এটির মধ্যে সর্বপ্রথম মারা যাওয়াও যেহেতু এটির ওজন প্রায় ৪২ এমবি (সার্ভারে বৃহত্তর প্রক্রিয়াগুলির মধ্যে একটি) হয়। এমনকি অ্যান্টমিলার মেরিটাল না হওয়া পর্যন্ত বার বার চালায়।
— ডেটালেস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.