Rsync ने एक एकल 50 GB फ़ाइल पर लिनक्स OOM हत्यारा ट्रिगर किया

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

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

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

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

यह कर्नेल 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 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

rsync oom oom-killer

— dataless
स्रोत

मैं कर्नेल क्रैश संदेशों को पढ़ने में कोई विशेषज्ञ नहीं हूं, लेकिन मैं वहां कोई संकेत नहीं देख सकता कि बी 32 जीबी कोर का उपयोग कर रहा था। इससे पहले कि हम इस धारणा पर आगे बढ़ें कि क्या आप इस बात की पुष्टि कर सकते हैं कि यह वर्तमान में है? क्योंकि 32 जीबी कोर के साथ मेमोरी-एग्जॉस्टिंग के बीच एक बड़ा अंतर है, और केवल 4 जीबी के साथ।

— MadHatter

टॉप आउटपुट के साथ अपडेट किया गया। यह गैर-रूट उपयोगकर्ता के रूप में उसी rsync आदेश को चलाने के बाद है। सुंदर सभी लेकिन अभी 1GB कैश के लिए उपयोग किया जाता है।

— डकैती

धन्यवाद। जैसा कि मैंने कहा, मैं कोई विशेषज्ञ नहीं हूँ - लेकिन यह जाँच के लायक था।

— MadHatter

आपको यह भी सत्यापित करना चाहिए कि आपका कर्नेल स्वैपिंग की अनुमति देता है (यानी, स्वैपिंग बंद नहीं हुई है) (और आपको डिस्क स्थान का एक बड़ा हिस्सा समर्पित करना चाहिए, मान लें कि 16 जीबी या 32 जीबी भी है)। नेट पर कुछ अजीब लोग स्वैपिंग को बंद करने की सलाह देते हैं, जो बहुत गलत है।

— ओलिवियर दुलक

@OlivierDulac आप किस सेटिंग की बात कर रहे हैं? स्वैप समर्थन संकलित है या हम स्वैप को माउंट करने में सक्षम नहीं होंगे, और 'स्वप्नशीलता' 60 पर सेट है। स्वैप आकार के लिए, क्या यह समस्या 32-बिट कर्नेल पर खराब नहीं होगी? उत्तर प्रतीत होता है कि कर्नेल डेटा संरचनाएं थीं जो हमें मार डाला। हम 32GB उपयोगकर्ता प्रक्रिया नहीं चला रहे हैं, हम बस इतना चाहते हैं कि डिस्क कैश के लिए, प्रदर्शन के लिए।

— 17

जवाबों:

178

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

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

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

order=0हमें बता रहा है कि कितनी स्मृति का अनुरोध किया जा रहा है। कर्नेल का मेमोरी प्रबंधन केवल 2 की शक्तियों में पृष्ठ संख्याओं का प्रबंधन करने में सक्षम है, इसलिए क्लैमड ने 2 ⁰ पृष्ठों की मेमोरी या 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

आपके मामले में, zonemask 0 है, जिसका अर्थ है कि clamd मेमोरी से अनुरोध कर रहा है 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इस प्रकार विशेष रूप से picky नहीं जा रहा है,।

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

[गिरी] [1772321.850770] सामान्य मुक्त: 8056kB मिनट: 8048kB कम: 10060kB उच्च: 12072kB active_anon: 0KB inactive_anon: 0KB active_file: 248kB inactive_file: 388kB unevictable: 0KB पृथक (anon): 0KB पृथक (फाइल): 0KB वर्तमान: 890008kB

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

ज़ोन के मेमोरी विखंडन पर कुछ और जानकारी यहाँ दी गई है:

]

मूल रूप से यह कहते हुए कि आपके पास 4MB का एक एकल पृष्ठ है जो मुख्य रूप से 4KB पेजों में बड़े पैमाने पर खंडित है।

तो चलो पुनर्कथन करें:

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

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

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

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

(जोर मेरा है)

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

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

यार, यह 2015 की बात है।

— -wabbit
स्रोत

जब मैंने ऊपर कहा " मैं कोई विशेषज्ञ नहीं हूं ", तो यह वही है जो मैं पढ़ने की उम्मीद कर रहा था। +1000, अगर मैं लेकिन कर सका; निश्चित के लिए +1। क्या शानदार जवाब है!

— MadHatter

वह सुन्दर था। अभी भी एसएफ के लिए उम्मीद है।

— रोमन

@ डेडलेस यस। मुझे संदेह है कि आपके सभी ZONE_NORMAL ऊपरी मेमोरी क्षेत्रों के बारे में मेटाडेटा से भरे हुए हैं। जब कोई उपयोगकर्ता प्रक्रिया मेमोरी पेजों का अनुरोध कर रही है, तो यह सबसे अधिक संभावना है कि ZONE_HIGHMEM (जो MM द्वारा ZONE_NORMAL में अपग्रेड किया जा सकता है, अगर हाईमेम के पास अनुरोध करने के लिए नि: शुल्क पेज नहीं हैं, लेकिन NORMAL है), इसलिए जब तक ZONE_HIGHMEM मेमोरी के दबाव में न हो। (तुम्हारा नहीं है), ZONE_NORMAL के पास कोई उपयोगकर्ता-स्थान प्रक्रिया नहीं होगी।

— wabbit

[कीबोर्ड पर मुट्ठियां मारता है] इस बाज़ को इनाम दें

— अंडरस्कोर_ड

@ wabbit हॉट नेटवर्क प्रश्न।

— कोडइन्चौस

कुछ बातें ...

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

Server_B में 32GB RAM है, इसलिए इसे 64GB स्वैप के लिए कॉन्फ़िगर करने का प्रयास करें। IMO, 2GB स्वैप स्पेस आपके सर्वर का तरीका बहुत कम है, विशेष रूप से सर्वर के लिए।

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

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

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

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

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

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

कुछ और बातें [अद्यतन]:

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

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

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

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

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

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

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

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

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

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

केंद्रीय प्रश्न: Os द्वारा rsync क्यों मारा जाता है? कौन / क्या स्मृति चबा रहा है?

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

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

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

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

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

स्थिति: <file_position>
झंडे: blah_blah
mnt_id: blah_blah

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

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

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

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

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

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

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

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

— क्रेग एस्टे
स्रोत

देखें कि एक उच्च मेमोरी सिस्टम पर कितना SWAP स्पेस है? - और आप अपने सिस्टम को 63GB स्वैप का उपयोग करते हुए नहीं देखना चाहते हैं। यह प्रयोग करने योग्य नहीं होगा।

— मार्टिन स्कोडर 20

यदि आप वीएम ओवरकम के बिना चलते हैं तो स्वैप> रैम केवल वास्तव में उपयोगी है, इसलिए कर्नेल को आवंटित पृष्ठों के लिए स्वैप स्थान आरक्षित करने की आवश्यकता होती है जब तक कि वे गंदगी न हों और वास्तविक भौतिक पृष्ठों की आवश्यकता होती है। वर्तमान अभ्यास ओवरकॉमिट करने की अनुमति देता है, और उन पृष्ठों को पृष्ठ से बाहर करने के लिए स्वैप स्थान की एक छोटी राशि के साथ चलता है जो केवल स्टार्टअप पर छुआ गया था और सामान्य ऑपरेशन में आवश्यक नहीं हैं। ओवरकमिट = 0 छोटे स्वैप के साथ ठीक है यदि आपके पास अधिकांश सिस्टम के लिए बहुत अधिक रैम है।

— पीटर कॉर्ड्स

ऐसा प्रतीत होता है कि rsync वास्तव में > 32GB का उपयोग करने की कोशिश कर रहा है, इसलिए इसके लिए स्वैप आवश्यक है। यही है, rsync इस फ़ाइल के लिए 50GB का उपयोग करने जा रहा है। 2x 30 वर्षों के लिए एक कोशिश और सच्चा मीट्रिक रहा है। चूंकि 6TB डिस्क ~ $ 300 है, इसलिए कोई कारण नहीं है। इस सर्वर पर और क्या चल सकता है जो सामूहिक रूप से रैम की सीमा से अधिक होगा?

— क्रेग एस्टे

@ क्रेगस्टी 64 जीबी स्वैप पूरी तरह से हास्यास्पद है क्योंकि मैंने पहले ही कहा था कि हमारे पास बड़ी उपयोगकर्ता प्रक्रियाएं नहीं हैं, हम केवल डिस्क कैश चाहते हैं, और जैसा कि मेरा लॉग दिखाया गया था, हम दुर्घटना के समय जीरो स्वैप का उपयोग कर रहे थे। शून्य। इसके अलावा rsync एक 50GB फ़ाइल पर भी 600KB RAM का उपयोग करता है। मेरा प्रारंभिक भ्रम यह था कि शायद लिनक्स डिस्क कैश पर पकड़ बना रहा था। और अंत में, मैं कुछ संख्याओं या प्रलेखन को देखना चाहता हूं कि कर्नेल अपने स्वैप स्थान को ट्रैक करने के लिए कितनी मेमोरी का उपयोग करता है इससे पहले कि मैं इस बॉक्स में कोई और जोड़ दूं।

— डकैती

@ डेडलेस मैंने अतिरिक्त जानकारी जोड़ी है जो पूरी तरह से बताती है कि क्या हो रहा है और क्यों। rsync है malloc / mmap के माध्यम से स्मृति हथियाने और यह 50GB के लिए इससे पहले कि यह किया है जाना होगा। अद्यतन अनुभाग देखें। इसमें ऐसे परीक्षण हैं जो साबित कर सकते हैं / जो मैं कह रहा हूं उसे अस्वीकार कर सकता हूं और आप परीक्षण के लिए शुरू में जोड़े गए स्वैप को छोड़ सकते हैं। BTW, मैं 40+ वर्षों से कर्नेल / ड्राइवर की प्रोग्रामिंग कर रहा हूं - मुझे बस कुछ ऐसा पता चल सकता है जो आप नहीं करते हैं, इसलिए कृपया टोन को मॉडरेट करें - मैं मदद करने की कोशिश कर रहा हूं ।

— क्रेग एस्टे

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

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

— ऊ।
स्रोत

मुझे नहीं पता था कि यह एक ऐसी बात थी, जो क्लैमव कर सकता था ... लेकिन नहीं, हम केवल क्लैम से इसके लिए पाई गई विशिष्ट फाइलों को स्कैन करते हैं। इसके अलावा, 32-बिट, इसलिए क्लैमव का कोई खतरा सभी सिस्टम मेमोरी को हॉगिंग नहीं करता है। (आप देखते हैं कि हमने क्यों सोचा था कि 32-बिट अभी भी एक अच्छा विचार है?)

— दुर्दांत

लिनक्स कर्नेल रिपोर्ट कर रहा है कि क्लैड वह प्रक्रिया है जिसके मेमोरी आवंटन अनुरोध ओओएम किलर को आमंत्रित कर रहे हैं - क्लैमव लगभग निश्चित रूप से माध्यमिक कारण है (प्राथमिक कारण पर्याप्त मेमोरी नहीं है)। चाहे वह ऑन-एक्सेस स्कैनिंग हो या कोई अन्य कॉन्फ़िगरेशन, सभी संकेत क्लैमव की ओर इशारा करते हैं।

— ऊ।

अगली बार जब आप rsync शुरू करते हैं, तो शीर्ष चलाएं और clamd प्रक्रिया के निवासी आकार की निगरानी करें।

— ऊ।

क्लैम ऊद किलर को आह्वान करने की पहली प्रक्रिया थी, लेकिन यह भी मरने वाला पहला व्यक्ति था क्योंकि इसका वजन लगभग 42 एमबी (सर्वर पर बड़ी प्रक्रियाओं में से एक) है। ओओम_किलर इसके बाद बार-बार चलता है जब तक कि मेटलोग की मौत नहीं हो जाती।

— पातड़ां