सवाल रुपयेसीएनसी ने लिनक्स ओओएम किलर को एक 50 जीबी फाइल पर ट्रिगर किया


मेरे पास server_A पर एक 50 जीबी फ़ाइल है, और मैं इसे server_B पर कॉपी कर रहा हूं। मै भागा

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

सर्वरबीबी में 2 जीबी स्वैप के साथ 32 जीबी रैम है। यह ज्यादातर निष्क्रिय है और बहुत सी मुफ्त रैम होना चाहिए था। इसमें डिस्क की बहुत सारी जगह है। लगभग 32 जीबी पर, स्थानांतरण बंद हो गया क्योंकि दूरस्थ पक्ष कनेक्शन बंद कर दिया।

सर्वरबी ने अब नेटवर्क छोड़ दिया है। हम डेटा केंद्र को इसे रीबूट करने के लिए कहते हैं। जब मैं क्रैश होने से पहले कर्नेल लॉग को देखता हूं, तो मुझे लगता है कि यह स्वैप के 0 बाइट्स का उपयोग कर रहा था, और प्रक्रिया सूची बहुत कम स्मृति का उपयोग कर रही थी (rsync प्रक्रिया 600 KB रैम का उपयोग करने के रूप में सूचीबद्ध थी), लेकिन oom_killer था जंगली जा रहा है, और लॉग में आखिरी चीज है जहां यह मेटालॉग के कर्नेल रीडर प्रक्रिया को मारता है।

यह कर्नेल 3.2.5 9, 32-बिट है (इसलिए कोई प्रक्रिया 4 जीबी से भी अधिक मैप कर सकती है)।

यह लगभग है जैसे लिनक्स लंबे समय तक चलने वाले डेमॉन की तुलना में कैशिंग को अधिक प्राथमिकता देता है। क्या देता है?? और मैं इसे फिर से होने से कैसे रोक सकता हूं?

ओम_किल्लर का आउटपुट यहां दिया गया है:

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 vm पैरामीटर यहां दिए गए हैं:

# 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

65
2017-09-24 06:36


मूल


मैं कर्नेल क्रैश संदेशों को पढ़ने में कोई विशेषज्ञ नहीं हूं, लेकिन मुझे वहां कोई संकेत नहीं दिख रहा है कि बी 32 जीबी कोर का उपयोग कर रहा था। इससे पहले कि हम इस धारणा पर आगे बढ़ें, क्या आप पुष्टि कर सकते हैं कि यह वर्तमान में है? क्योंकि 32 जीबी कोर के साथ एक बॉक्स को स्मृति-थकाऊ और केवल 4 जीबी के बीच एक बड़ा अंतर है। - MadHatter
शीर्ष आउटपुट के साथ अपडेट किया गया। यह एक ही rsync कमांड को गैर रूट उपयोगकर्ता के रूप में चलाने के बाद है। अभी बहुत कुछ 1 जीबी का उपयोग कैश के लिए किया जाता है। - dataless
धन्यवाद। जैसा कि मैंने कहा, मैं कोई विशेषज्ञ नहीं हूं - लेकिन यह जांच करने लायक लग रहा था। - MadHatter
आपको यह भी सत्यापित करना चाहिए कि आपका कर्नेल स्वैपिंग की अनुमति देता है (यानी, स्वैपिंग बंद नहीं है) (और आपको डिस्क स्पेस का बड़ा हिस्सा समर्पित करना चाहिए, आइए 16 जीबी या 32 जीबी भी कहें)। नेट पर कुछ अजीब व्यक्ति स्वैपिंग बंद करने की सलाह देते हैं, जो बहुत गलत है। - Olivier Dulac
@OlivierDulac आप किस सेटिंग का जिक्र कर रहे हैं? स्वैप समर्थन संकलित किया गया है या हम स्वैप को माउंट करने में सक्षम नहीं होंगे, और 'swappiness' 60 पर सेट हो गया है। स्वैप आकार के लिए, क्या यह 32-बिट कर्नेल पर समस्या को और भी खराब नहीं करेगा? जवाब प्रकट होता है कि कर्नेल डेटा संरचनाएं हमें मार डालीं। हम 32 जीबी उपयोगकर्ता प्रक्रियाओं को नहीं चला रहे हैं, हम सिर्फ प्रदर्शन के लिए डिस्क कैश के लिए बहुत अधिक RAM चाहते हैं। - dataless


जवाब:


तो चलो ओम-किलर आउटपुट पढ़ें और देखें कि वहां से क्या सीखा जा सकता है।

ओओएम किलर लॉग का विश्लेषण करते समय, यह देखना महत्वपूर्ण है कि इसे किसने ट्रिगर किया। आपके लॉग की पहली पंक्ति हमें कुछ सुराग देती है:

[कर्नेल] [1772321.850644] क्लैमड ने ओम-किलर का आह्वान किया: gfp_mask = 0x84d0, ऑर्डर = 0

order=0 हमें बता रहा है कि कितनी मेमोरी का अनुरोध किया जा रहा है। कर्नेल का मेमोरी प्रबंधन केवल 2 की शक्तियों में पृष्ठ संख्याओं को प्रबंधित करने में सक्षम है, इसलिए क्लैमड ने 2 से अनुरोध किया है0 स्मृति या 4 केबी के पेज।

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 */

के अनुसार लिनक्स एमएम दस्तावेज, इसलिए आपके अपेक्षित के लिए झंडे हैं GFP_ZERO, GFP_REPEAT, GFP_FS, GFP_IO तथा GFP_WAIT, इस प्रकार विशेष रूप से picky नहीं जा रहा है।

तो क्या हो रहा है ZONE_NORMAL? ओओएम आउटपुट में कुछ सामान्य आंकड़े आगे मिल सकते हैं:

[कर्नेल] [1772321.850770] सामान्य मुफ्त: 8056 केबी न्यूनतम: 8048 केबी कम: 10060 केबी उच्च: 12072kB active_anon: 0kB inactive_anon: 0kb active_file: 248kB inactive_file: 388kB अपरिहार्य: 0kB पृथक (एनन)   : 0 केबी पृथक (फ़ाइल): 0 केबी उपस्थित: 890008 केबी

यहां ध्यान देने योग्य है free से सिर्फ 8 के लिए है min और नीचे रास्ता low। इसका मतलब है कि आपके होस्ट का मेमोरी मैनेजर कुछ हद तक परेशान है और kswapd को पहले से ही पृष्ठों को स्वैप करना चाहिए पीला नीचे दिए गए ग्राफ का चरण: Linux memory manager graph

क्षेत्र के स्मृति विखंडन पर कुछ और जानकारी यहां दी गई है:

[कर्नेल] [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 केबी

मूल रूप से यह बताते हुए कि आपके पास 4 एमबी का एक ही संगत पृष्ठ है, जिसमें शेष मुख्य रूप से 4 केबी पृष्ठों में विभाजित हैं।

तो आइए दोबारा दोबारा दोहराएं:

  • आपके पास उपयोगकर्तालैंड प्रक्रिया है (clamd) से स्मृति प्राप्त करना ZONE_NORMAL जबकि गैर-विशेषाधिकार प्राप्त स्मृति आवंटन आमतौर पर किया जाएगा ZONE_HIMEM
  • मेमोरी मैनेजर को इस चरण में अनुरोधित 4K पृष्ठ की सेवा करने में सक्षम होना चाहिए, हालांकि आपको लगता है कि इसमें महत्वपूर्ण स्मृति दबाव है ZONE_NORMAL
  • प्रणाली, द्वारा kswapdनियम, चाहिए पहले कुछ पेजिंग गतिविधि देखी है, लेकिन मेमोरी दबाव में भी कुछ भी नहीं बदला जा रहा है ZONE_NORMALस्पष्ट कारण के बिना
  • उपरोक्त में से कोई भी क्यों एक निश्चित कारण देता है oom-killer आह्वान किया गया है

यह सब अजीब लगता है, लेकिन कम से कम इसमें वर्णित से संबंधित होना चाहिए जॉन ओ'गोरमन के उत्कृष्ट "लिनक्स वर्चुअल मेमोरी मैनेजर" पुस्तक को समझने के खंड 2.5:

चूंकि कर्नेल (ZONE_NORMAL) द्वारा उपयोग किए जाने वाले पते स्थान आकार में सीमित हैं, कर्नेल को उच्च मेमोरी की अवधारणा के लिए समर्थन है। [...] 1 जीआईबी और 4 जीआईबी की सीमा के बीच मेमोरी तक पहुंचने के लिए, कर्नेल अस्थायी रूप से उच्च स्मृति से पेजों को kmap () के साथ ZONE_NORMAL में मानचित्रित करता है। [...]

इसका मतलब है कि 1 जीबीबी मेमोरी का वर्णन करने के लिए, लगभग 11 एमआईबी कर्नेल मेमोरी की आवश्यकता है। इस प्रकार, 16 जीआईबी के साथ, 176 एमआईबी मेमोरी का उपभोग किया जाता है, जो ZONE_NORMAL पर महत्वपूर्ण दबाव डालता है। यह तब तक खराब नहीं होता जब तक अन्य संरचनाओं को ध्यान में रखा जाता है जो ZONE_NORMAL का उपयोग करते हैं। पृष्ठ सारणी प्रविष्टियों (पीटीई) जैसी बहुत छोटी संरचनाओं को भी सबसे खराब मामले में लगभग 16 एमआईबी की आवश्यकता होती है। यह x86 पर उपलब्ध भौतिक स्मृति लिनक्स के लिए व्यावहारिक सीमा के बारे में 16 जीआईबी बनाता है

(जोर मेरा है)

चूंकि 3.2 में 2.6 से अधिक मेमोरी प्रबंधन में कई प्रगति हुई है, यह एक निश्चित उत्तर नहीं है, लेकिन वास्तव में एक मजबूत संकेत मैं पहले पीछा करता हूं। मेजबान की उपयोग करने योग्य मेमोरी को या तो 16 जी पर इस्तेमाल करके कम करें mem= कर्नेल पैरामीटर या सर्वर से बाहर डीआईएमएम के आधे भाग को फिसलने से।

अंत में, 64-बिट कर्नेल का उपयोग करें

दोस्त, यह 2015 है।


179
2017-09-24 10:46



जब मैंने ऊपर कहा "मैं कोई विशेषज्ञ नहीं हूँ", इस मैं जो पढ़ने की उम्मीद कर रहा था वह है। +1000, अगर मैं कर सकता था; निश्चित रूप से +1। क्या एक अच्छा जवाब है! - MadHatter
वह सुन्दर था। एसएफ के लिए अभी भी उम्मीद है। - Roman
@ प्रसव हां। मुझे संदेह है कि आपके सभी ZONE_NORMAL ऊपरी मेमोरी क्षेत्रों के बारे में मेटाडेटा से भरे हुए हैं। जब उपयोगकर्तालैंड प्रक्रिया मेमोरी पेजों का अनुरोध कर रही है, तो संभवतः ज़ोनE_HIGHMEM का अनुरोध करने जा रहा है (जिसे एमएम द्वारा ZONE_NORMAL में अपग्रेड किया जा सकता है यदि HIGHMEM के पास अनुरोध करने के लिए कोई और अधिक मुफ्त पृष्ठ नहीं है लेकिन नॉर्मल है), इसलिए जब तक ZONE_HIGHMEM स्मृति दबाव में नहीं है (आपका नहीं है), ZONE_NORMAL में कोई उपयोगकर्ता-स्थान प्रक्रिया नहीं होगी। - the-wabbit
[कीबोर्ड पर मुट्ठी झुकाव] इस खरगोश को बक्षीस दें - underscore_d
@ the-wabbit हॉट नेटवर्क प्रश्न। - CodesInChaos


कुछ बातें ...

स्वैप स्पेस के अंगूठे का मेरा नियम कम से कम 2x भौतिक राम की मात्रा में होना चाहिए। यह पृष्ठ / स्वैप डिमन को कुशलता से स्मृति को पुन: व्यवस्थित करने की क्षमता देता है।

सर्वर_B में 32 जीबी रैम है, इसलिए 64 जीबी स्वैप के लिए इसे कॉन्फ़िगर करने का प्रयास करें। आईएमओ, आपके सर्वर के 2 जीबी स्वैप स्पेस है मार्ग बहुत कम, खासकर एक सर्वर के लिए।

यदि आपके पास एक अतिरिक्त विभाजन नहीं है जिसे आप स्वैप विभाजन में बना सकते हैं, तो आप इसे फ़ाइल बनाकर और स्वैप विभाजन के रूप में आरोहित करके इसका परीक्षण कर सकते हैं [यह धीमा हो जाएगा]। देख https://www.maketecheasier.com/swap-partitions-on-linux/

चूंकि server_B में डिस्क की बहुत सारी जगह है, - जगह की आवश्यकता नहीं है, और यह अवांछित हो सकता है क्योंकि यह 32 जीबी का उपयोग करने के लिए rsync का कारण बन सकता है। - जगह केवल तभी उपयोगी होती है जब आप फाइल सिस्टम स्पेस [जो आप नहीं हैं] पर कम हों या कुछ विशेष प्रदर्शन आवश्यकता हो।

मेरा अनुमान है कि rsync आपके वर्तमान विकल्पों के साथ 50 जीबी रैम [फ़ाइल आकार] का उपयोग करना चाहता है। आम तौर पर, rsync को अपनी नौकरी करने के लिए उस स्मृति की आवश्यकता नहीं होती है, इसलिए आपके एक या अधिक विकल्प समस्या हो सकती हैं। मैं बिना किसी समस्या के 200 जीबी फाइलों को स्थानांतरित करता हूं।

कोई विकल्प का उपयोग कर कुछ टेस्ट रन करें। छोटी फ़ाइलों के साथ ऐसा करें, 10 जीबी कहें - इसे कर्नेल पैनिक को रोकना चाहिए, लेकिन फिर भी आपको समस्या का कारण बनने वाले व्यवहार की निगरानी करने की अनुमति मिलती है। Rsync के स्मृति उपयोग की निगरानी करें।

धीरे-धीरे, एक विकल्प में वापस विकल्प जोड़ें, यह देखने के लिए कि कौन सा विकल्प [या विकल्पों का संयोजन] rsync को राम पर पिगिंग शुरू करने का कारण बनता है (उदाहरण के लिए स्थानांतरण हो रहा है, rsync का राम उपयोग स्थानांतरित डेटा डेटा की मात्रा के अनुपात में आनुपातिक रूप से बढ़ता है, आदि।)।

यदि आपको वास्तव में उन विकल्पों की आवश्यकता है जो rsync को कुछ इन-रैम फ़ाइल छवि रखने के लिए कारण बनती हैं, तो आपको अतिरिक्त स्वैप स्पेस की आवश्यकता होगी और आपका अधिकतम फ़ाइल आकार तदनुसार सीमित होगा।

कुछ और चीजें [अद्यतन]:

(1) कर्नेल स्टैक ट्रेसबैक से पता चलता है कि rsync पृष्ठ को एमएमएपी क्षेत्र पर दोषपूर्ण कर रहा था। यह शायद फ़ाइल को mmaping है। mmap कोई गारंटी नहीं देता है कि यह डिस्क पर फ्लश करेगा जब तक फ़ाइल बंद है [पढ़ने / लिखने के विपरीत] जो तुरंत एफएस ब्लॉक कैश में जाती है [जहां इसे फ़्लश किया जाएगा]

(2) कर्नेल क्रैश / पैनिक तब होता है जब स्थानांतरण आकार रैम के आकार को हिट करता है। स्पष्ट रूप से rsync malloc या mmap के माध्यम से उस गैर-fscache स्मृति को पकड़ रहा है। एक बार फिर, आपके द्वारा निर्दिष्ट विकल्पों के साथ, rsync 50GB फ़ाइल को स्थानांतरित करने के लिए 50GB स्मृति आवंटित करेगा।

(3) एक 24 जीबी फ़ाइल स्थानांतरित करें। वह शायद काम करेगा। फिर, कर्नेल को mem = 16G के साथ बूट करें और फिर से 24 जीबी फ़ाइल परीक्षण करें। यह 32 जीबी की बजाय 16 जीबी पर उड़ाएगा। यह पुष्टि करेगा कि rsync वास्तव में स्मृति की जरूरत है।

(4) इससे पहले कि आप कहें कि स्वैप जोड़ना हास्यास्पद है, कुछ [स्वैप-टू-फाइल विधि के माध्यम से] जोड़ने का प्रयास करें। स्वैप की आवश्यकता नहीं है इसके बारे में सभी अकादमिक तर्कों की तुलना में यह करना और परीक्षण करना कहीं अधिक आसान है। यहां तक ​​कि यदि यह समाधान नहीं है, तो आप इससे कुछ सीख सकते हैं। मैं शर्त लगाऊंगा कि mem = 16G परीक्षण बिना आतंक / क्रैश के सफल होगा।

(5) संभावना है कि rsync है स्वैप मारना, लेकिन ओओएम में आने से पहले शीर्ष पर देखने के लिए यह बहुत तेज होता है और rsync को मारता है। जब तक rsync 32 जीबी तक पहुंच जाता है, तब तक अन्य प्रक्रियाओं को स्वैप करने के लिए मजबूर कर दिया गया है, खासकर यदि वे निष्क्रिय हैं। शायद, "मुक्त" और "शीर्ष" का संयोजन आपको एक बेहतर तस्वीर देगा।

(6) rsync मारे जाने के बाद, एफएस में एमएमएपी फ्लश करने में समय लगता है। ओओएम के लिए पर्याप्त तेज़ नहीं है और यह अन्य चीजों को मारना शुरू कर देता है [कुछ स्पष्ट रूप से मिशन महत्वपूर्ण हैं]। यही है, एमएमएपी फ्लश और ओओएम रेसिंग कर रहे हैं। या, ओओएम एक बग है। अन्यथा, एक दुर्घटना नहीं होगी।

(7) मेरे अनुभव में, एक बार सिस्टम "मेमोरी वॉल हिट करता है", लिनक्स पूरी तरह से ठीक होने में काफी समय लगता है। और, कभी-कभी यह वास्तव में ठीक से ठीक नहीं होता है और इसे साफ़ करने का एकमात्र तरीका रीबूट होता है। उदाहरण के लिए, मेरे पास 12 जीबी रैम है। जब मैं नौकरी चलाता हूं जो 40 जीबी मेमोरी का उपयोग करता है [मेरे पास बड़ी नौकरियों को समायोजित करने के लिए 120 जीबी स्वैप है] और फिर इसे मार दें, सिस्टम को सामान्य प्रतिक्रिया में वापस आने में लगभग 10 मिनट लगते हैं [डिस्क पर प्रकाश प्रकाश के साथ हर समय] ।

(8) rsync चलाएं के बिना विकल्प। यह काम करेगा। से काम करने के लिए आधारभूत उदाहरण प्राप्त करें। फिर वापस जोड़ें - जगह और retest। फिर इसके बजाय - सत्यापित करें-सत्यापित करें। फिर, दोनों कोशिश करें। पता लगाएं कि कौन सा विकल्प rsync विशाल mmap कर रहा है। फिर तय करें कि आप इसके बिना जी सकते हैं या नहीं। अगर - जगह अपराधी है, तो यह कोई ब्रेनर नहीं है, क्योंकि आपके पास बहुत सी डिस्क स्पेस है। यदि आपके पास विकल्प होना चाहिए, तो आपको rsync करने वाले malloc / mmap को समायोजित करने के लिए स्वैप स्थान प्राप्त करना होगा।

दूसरा अद्यतन:

कृपया उपरोक्त से mem = और छोटे फ़ाइल परीक्षण करें।

केंद्रीय प्रश्न: ओओएम द्वारा आरएसआईएनसी क्यों मारा जाता है? च्यूइंग मेमोरी कौन / क्या है?

मैंने सिस्टम को 32 बिट होने के बारे में पढ़ा [लेकिन भूल गया]। इसलिए, मैं सहमत हूं, rsync सीधे उत्तरदायी नहीं हो सकता है (malloc / mmap के माध्यम से - glibc अज्ञात / निजी mmaps के माध्यम से बड़े mallocs लागू करता है), और rsync की mmap पेज गलती सिर्फ संयोग से ओओएम को ट्रिगर करती है। फिर, ओओएम सीधे और परोक्ष रूप से [एफएस कैश, सॉकेट बफर, आदि] द्वारा खपत कुल स्मृति की गणना करता है और यह मुख्य उम्मीदवार का निर्णय लेता है। तो, कुल मेमोरी उपयोग की निगरानी सहायक हो सकती है। मुझे संदेह है कि यह फाइल स्थानांतरण के समान दर पर गिरता है। जाहिर है, यह नहीं होना चाहिए।

कुछ चीजें जिन्हें आप एक फास्ट लूप में एक पर्ल या पायथन स्क्रिप्ट के माध्यम से / proc या / proc / rsync_pid में मॉनीटर कर सकते हैं [एक बैश स्क्रिप्ट संभवतः अंत-दुनिया की घटना के लिए पर्याप्त तेज़ नहीं होगी] जो सभी की निगरानी कर सकती है निम्नलिखित कई सौ बार / सेकंड। आप इसे rsync की तुलना में उच्च प्राथमिकता पर चला सकते हैं, इसलिए यह स्वयं को रैम में रखेगा और चल रहा है ताकि आप क्रैश से पहले चीजों की निगरानी कर सकें और उम्मीद है कि ओओएम के दौरान आप देख सकते हैं कि ओओएम पागल क्यों है:

/ proc / meminfo - "प्रभाव बिंदु" पर स्वैप उपयोग पर अधिक बढ़िया अनाज प्राप्त करने के लिए। असल में, अंतिम संख्या प्राप्त करने पर कुल रैम का उपयोग किया जा रहा है, यह अधिक उपयोगी हो सकता है। जबकि शीर्ष यह प्रदान करता है, यह "बड़ी धमाके" से पहले ब्रह्मांड की स्थिति को दिखाने के लिए पर्याप्त तेज़ नहीं हो सकता है (उदाहरण के लिए अंतिम 10 मिलीसेकंड)

/ proc / rsync_pid / fd निर्देशिका। सिम्लिंक पढ़ने से आप यह पहचानने की अनुमति देंगे कि लक्ष्य फ़ाइल पर कौन सा एफडी खोला गया है (उदा। / Proc / rsync_pid / fd / 5 -> target_file का रीडलिंक)। यह शायद एफडी संख्या प्राप्त करने के लिए केवल एक बार किया जाना चाहिए [इसे तय रहना चाहिए]

एफडी संख्या को जानना, / proc / rsync_pid / fdinfo / fd देखें। यह एक टेक्स्ट फ़ाइल है जो इस तरह दिखती है:

pos: <file_position>
झंडे: blah_blah
mnt_id: blah_blah

"Pos" मान की निगरानी करना सहायक हो सकता है क्योंकि "अंतिम फ़ाइल स्थिति" उपयोगी हो सकती है। यदि आप अलग-अलग आकार और mem = विकल्पों के साथ कई परीक्षण करते हैं, तो आखिरी फ़ाइल स्थिति इनमें से किसी एक को ट्रैक करती है [और कैसे]? सामान्य संदिग्ध: फ़ाइल स्थिति == उपलब्ध रैम

लेकिन, सबसे आसान तरीका "rsync local_file सर्वर: remote_file" से शुरू करना है और यह कार्य सत्यापित करता है। आप "ssh server rsync file_a file_b" कर कर समान [लेकिन तेज़] परिणाम प्राप्त करने में सक्षम हो सकते हैं [आपको पहले 50GB file_a बनाना होगा]। File_a बनाने का एक आसान तरीका scp local_system है: original_file सर्वर: file_a और यह स्वयं के लिए दिलचस्प हो सकता है (उदाहरण के लिए यह काम करता है जब rsync क्रैश हो जाता है? यदि scp काम करता है, लेकिन rsync विफल रहता है, तो यह rsync को इंगित करता है। यदि scp विफल रहता है, तो यह बिंदु एनआईसी चालक की तरह कुछ और करने के लिए)। एसएसएच आरएसआईएनसी करना एनआईसी को समीकरण से बाहर ले जाता है, जो सहायक हो सकता है। अगर वह सिस्टम को खो देता है, तो कुछ वास्तव में गलत है। यदि यह सफल होता है, [जैसा कि मैंने उल्लेख किया है] विकल्पों को एक-एक करके वापस जोड़ना शुरू करें।

मुझे बिंदु को कम करने से नफरत है, लेकिन स्वैप-टू-फाइल के माध्यम से कुछ स्वैप जोड़ना क्रैश व्यवहार को बदल सकता है / देरी हो सकता है और यह नैदानिक ​​उपकरण के रूप में उपयोगी हो सकता है। यदि जोड़ना है, तो 16 जीबी कहें, स्वैप में 32 जीबी से 46 जीबी तक दुर्घटना में देरी [स्मृति उपयोग या लक्ष्य फ़ाइल स्थिति द्वारा मापा गया], तो वह कुछ कहेंगे।

यह कोई विशेष प्रक्रिया नहीं हो सकती है, लेकिन एक गलती कर्नेल ड्राइवर जो चबाने वाली स्मृति है। कर्नेल का आंतरिक vmalloc सामान आवंटित करता है और इसे बाहर बदला जा सकता है। आईआईआरसी, यह सभी परिस्थितियों में पता योग्यता से बंधे नहीं है।

जाहिर है, ओओएम भ्रमित / घबरा रहा है। यही है, यह rsync को मारता है, लेकिन स्मृति को समय-समय पर मुक्त नहीं किया जाता है और अन्य पीड़ितों की तलाश में जाता है। उनमें से कुछ शायद सिस्टम ऑपरेशन के लिए महत्वपूर्ण हैं।

मॉलोक / एमएमएपी को अलग करता है, यह असफल एफएस कैश के कारण हो सकता है जो लंबे समय तक लेता है (उदाहरण के लिए 30 जीबी अनलॉक डेटा के साथ, 300 एमबी / सेकंड की डिस्क दर मानते हुए, इसे फ्लश करने में 100 सेकंड लग सकते हैं)। यहां तक ​​कि उस दर पर, ओओएम बहुत अधीर हो सकता है। या, ओओएम हत्या rsync एफएस फ्लश पर्याप्त तेजी से शुरू नहीं करता है [या बिल्कुल]। या एफएस फ्लश पर्याप्त तेज़ी से होता है, लेकिन इसमें मुफ्त पूल में पृष्ठों की "आलसी" रिलीज होती है। कुछ / proc विकल्प हैं जिन्हें आप एफएस कैश व्यवहार को नियंत्रित करने के लिए सेट कर सकते हैं [मुझे याद नहीं है कि वे क्या हैं]।

Mem = 4G या कुछ अन्य छोटी संख्या के साथ बूट करने का प्रयास करें। यह एफएस कैश पर वापस कटौती कर सकता है और ओओएम को अन्य चीज़ों को मारने से बचाने के लिए अपने फ्लश टाइम को छोटा कर सकता है (उदाहरण के लिए फ्लश टाइम 100 सेकंड से घटाकर <1 सेकेंड) हो जाता है। यह एक ओओएम बग भी अनमास्क कर सकता है जो 32 बिट सिस्टम या कुछ ऐसे पर भौतिक राम> 4 जीबी को संभाल नहीं सकता है।

इसके अलावा, एक महत्वपूर्ण बिंदु: गैर रूट के रूप में चलाएं। रूट उपयोगकर्ताओं को कभी भी संसाधनों को चबाने की उम्मीद नहीं की जाती है, इसलिए उन्हें अधिक क्षमा करने वाली सीमाएं दी जाती हैं (उदाहरण के लिए गैर-मूल उपयोगकर्ताओं के लिए 9 5% बनाम स्मृति का 99%)। यह समझा सकता है कि ओओएम ऐसे राज्य में क्यों है। इसके अलावा, यह ओओएम एट देता है। अल। स्मृति पुनः प्राप्त करने के अपने काम करने के लिए और अधिक हेडरूम।


4
2017-09-27 20:30



देख एक उच्च स्मृति प्रणाली पर कितना SWAP स्थान? - और आप अपने सिस्टम को 63 जीबी स्वैप का उपयोग नहीं देखना चाहते हैं। यह प्रयोग योग्य नहीं होगा। - Martin Schröder
स्वैप> रैम केवल तभी उपयोगी होता है जब आप वीएम ओवरकमिट के बिना चलाते हैं, इसलिए कर्नेल को आवंटित पृष्ठों के लिए स्वैप स्पेस आरक्षित करने की आवश्यकता होती है जब तक उन्हें गंदगी न हो और उन्हें वास्तविक भौतिक पृष्ठों का समर्थन करने की आवश्यकता हो। वर्तमान अभ्यास ओवरकमिट की अनुमति देना है, और उन पृष्ठों को पृष्ठ पर पृष्ठों के लिए स्वैप स्पेस की थोड़ी मात्रा के साथ चलाएं जिन्हें स्टार्टअप पर ही स्पर्श किया गया था और सामान्य ऑपरेशन में इसकी आवश्यकता नहीं है। अधिकतर सिस्टम के लिए, यदि आपके पास बहुत सी रैम है तो छोटे स्वैप के साथ ओवरकॉइट = 0 ठीक है। - Peter Cordes
ऐसा लगता है कि वास्तव में rsync है 32 जीबी का उपयोग करने की कोशिश कर रहा है, इसलिए उसके लिए स्वैप की आवश्यकता है। यही है, rsync इस फ़ाइल के लिए 50 जीबी का उपयोग करने जा रहा है। 2x 30 साल के लिए एक कोशिश की और सही मीट्रिक रहा है। चूंकि 6TB डिस्क ~ $ 300 है, इसलिए इसका कोई कारण नहीं है। इस सर्वर पर और क्या चल रहा है जो सामूहिक रूप से रैम सीमा पर धक्का देगी? - Craig Estey
@CraigEstey 64 जीबी स्वैप पूरी तरह से हास्यास्पद है क्योंकि जैसा कि मैंने पहले कहा था कि हमारे पास बड़ी उपयोगकर्ता प्रक्रियाएं नहीं हैं, हम केवल डिस्क कैश चाहते हैं, और जैसा कि मेरा लॉग दिखाया गया है, हम दुर्घटना के समय शून्य स्वैप का उपयोग कर रहे थे। शून्य। 50 जीबी फ़ाइल पर भी rsync 600 केबी रैम का उपयोग करता है। मेरा प्रारंभिक भ्रम यह था कि शायद लिनक्स डिस्क कैश पर आक्रामक रूप से पकड़ रहा था। और आखिरकार, मैं कुछ नंबर या दस्तावेज देखना चाहता हूं कि कर्नेल इस स्वैप स्पेस को ट्रैक करने के लिए कितनी मेमोरी का उपयोग करता है इससे पहले कि मैं इस बॉक्स में और जोड़ूं। - dataless
@ प्रसव मैंने अतिरिक्त जानकारी जोड़ दी है जो पूरी तरह बताती है कि क्या हो रहा है और क्यों। rsync है मॉलोक / एमएमएपी के माध्यम से मेमोरी को पकड़ना और यह पूरा होने से पहले 50 जीबी तक जाएगा। अद्यतन खंड देखें। इसमें ऐसे परीक्षण हैं जो मैं जो कह रहा हूं उसे साबित / अस्वीकार कर सकता हूं और आप परीक्षण के लिए प्रारंभिक स्वैप को छोड़ सकते हैं। बीटीडब्लू, मैं 40+ सालों के लिए कर्नेल / ड्राइवर प्रोग्रामिंग कर रहा हूं - मुझे शायद कुछ ऐसा पता हो जो आप नहीं करते हैं, तो कृपया स्वर को छोटा करें - I कर रहा हूँ मदद करने की कोशिश कर रहा है। - Craig Estey


clamd? ऐसा लगता है कि आप क्लैमएवी का उपयोग कर रहे हैं और स्कैनिंग सक्षम है जहां एंटी-वायरस इंजन वायरस के लिए खुली फ़ाइलों को स्कैन करने का प्रयास करता है, स्मृति में लोड करके, किसी भी अन्य प्रक्रिया द्वारा खोले गए प्रत्येक फ़ाइल की पूरी सामग्री

आपके सुरक्षा मुद्रा और इस हस्तांतरण की आवश्यकता के आधार पर, आपको ट्रांसफर करने के दौरान क्लैमएवी ऑन-एक्सेस स्कैनिंग को अक्षम करने का मूल्यांकन करना चाहिए।


2
2017-09-28 10:34



मुझे पता नहीं था कि यह एक चीज भी था जो क्लैमव कर सकती थी ... लेकिन हम क्लैम से इसे केवल विशिष्ट फाइलों को स्कैन नहीं करते हैं। इसके अलावा, 32-बिट, इसलिए क्लैमव का कोई खतरा सभी सिस्टम मेमोरी को हॉगिंग नहीं करता है। (आप देखते हैं कि हमने 32-बिट क्यों सोचा था अभी भी एक अच्छा विचार था?) - dataless
लिनक्स कर्नेल रिपोर्ट कर रहा है कि क्लैमड वह प्रक्रिया है जिसका स्मृति आवंटन अनुरोध ओओएम हत्यारा का आह्वान कर रहा है - क्लैमएवी लगभग निश्चित रूप से द्वितीयक कारण है (प्राथमिक कारण पर्याप्त स्मृति नहीं है)। चाहे यह ऑन-एक्सेस स्कैनिंग या कुछ अन्य कॉन्फ़िगरेशन हो, सभी संकेत क्लैमएवी को इंगित करते हैं। - oo.
अगली बार जब आप rsync शुरू करेंगे, शीर्ष पर चलें और क्लैमड प्रक्रिया के निवासी आकार की निगरानी करें। - oo.
क्लैम ओम किलर का आह्वान करने वाली पहली प्रक्रिया थी, लेकिन इसके लिए मरने वाला पहला भी था क्योंकि इसका वजन लगभग 42 एमबी (सर्वर पर बड़ी प्रक्रियाओं में से एक) में होता है। Oom_killer तब तक बार-बार चलता है जब तक मेटलॉग भी नहीं मारा जाता है। - dataless