2015 में, मैंने उन उपकरणों के बारे में लिखा था जो रूबी प्रबंधित मेमोरी लीक का पता लगाने के लिए प्रदान करता है। ज्यादातर लेख में आसानी से प्रबंधनीय लीक के बारे में बात की गई थी। इस बार मैं उन टूल्स और ट्रिक्स के बारे में बात करूंगा जिनका उपयोग आप लीक को खत्म करने के लिए कर सकते हैं जो रूबी में विश्लेषण करना इतना आसान नहीं है। विशेष रूप से, मैं mwrap, heaptrack, iseq_collector और chap के बारे में बात करूंगा।

मानवरहित स्मृति लीक

यह छोटा सा कार्यक्रम मॉलॉक को सीधे कॉल के साथ एक लीक को उकसाता है। यह आरएसएस के 16 एमबी की खपत के साथ शुरू होता है, और 118 एमबी के साथ समाप्त होता है। कोड 1024 बाइट्स के 100 हज़ार ब्लॉक मेमोरी में रखता है और उनमें से 50 हज़ार को हटा देता है।

require 'fiddle' require 'objspace' def usage rss = `ps -p #{Process.pid} -o rss -h`.strip.to_i * 1024 puts "RSS: #{rss / 1024} ObjectSpace size #{ObjectSpace.memsize_of_all / 1024}" end def leak_memory pointers = [] 100_000.times do i = Fiddle.malloc(1024) pointers << i end 50_000.times do Fiddle.free(pointers.pop) end end usage # RSS: 16044 ObjectSpace size 2817 leak_memory usage # RSS: 118296 ObjectSpace size 3374 

हालाँकि आरएसएस ११, एमबी का है, लेकिन हमारी रूबी वस्तु केवल तीन मेगाबाइट के बारे में पता है। विश्लेषण में, हम इस बहुत बड़ी स्मृति रिसाव का केवल एक बहुत छोटा हिस्सा देखते हैं।

इस तरह के रिसाव का एक वास्तविक उदाहरण ओलेग दासशेवस्की द्वारा वर्णित है , मैं इस अद्भुत लेख को पढ़ने की सलाह देता हूं।

Mwrap लागू करें

रूबी के लिए मेवाप एक मेमोरी प्रोफाइलर है जो मॉलॉक और इस परिवार के अन्य कार्यों को रोककर स्मृति में सभी डेटा आवंटन की निगरानी करता है। यह LD_PRELOAD का उपयोग करके उस स्थान और निःशुल्क मेमोरी को कॉल करता है। यह गिनती के लिए liburcu का उपयोग करता है और सी और रूबी कोड में प्रत्येक कॉल बिंदु के लिए आवंटन और विलोपन काउंटर को ट्रैक कर सकता है। Mwrap आकार में छोटा है, लगभग एक राष्ट्रीयकृत कार्यक्रम के लिए RSS जितना बड़ा है, और लगभग दोगुना है।

यह अपने बहुत छोटे आकार और रूबी समर्थन में कई अन्य पुस्तकालयों से भिन्न है। यह रूबी फाइलों में स्थानों को ट्रैक करता है और वेलग्रिंड + मसिफ सी-लेवल बैकट्रैक और समान प्रोफाइलरों तक सीमित नहीं है। यह समस्याओं के स्रोतों को अलग करने को बहुत सरल करता है।

प्रोफाइलर का उपयोग करने के लिए, आपको एप्लिकेशन को Mwrap शेल के माध्यम से चलाने की आवश्यकता है, यह LD_PRELOAD वातावरण को लागू करेगा और रूबी बाइनरी को चलाएगा।

आइए हमारी स्क्रिप्ट में Mwrap जोड़ें:

 require 'mwrap' def report_leaks results = [] Mwrap.each do |location, total, allocations, frees, age_total, max_lifespan| results << [location, ((total / allocations.to_f) * (allocations - frees)), allocations, frees] end results.sort! do |(_, growth_a), (_, growth_b)| growth_b <=> growth_a end results[0..20].each do |location, growth, allocations, frees| next if growth == 0 puts "#{location} growth: #{growth.to_i} allocs/frees (#{allocations}/#{frees})" end end GC.start Mwrap.clear leak_memory GC.start # Don't track allocations for this block Mwrap.quiet do report_leaks end 

अब स्क्रिप्ट को Mwrap आवरण के साथ चलाएं:

 % gem install mwrap % mwrap ruby leak.rb leak.rb:12 growth: 51200000 allocs/frees (100000/50000) leak.rb:51 growth: 4008 allocs/frees (1/0) 

Mwrap ने स्क्रिप्ट में एक रिसाव का सही पता लगाया (50,000 * 1024)। और न केवल निर्धारित किया गया, बल्कि एक विशिष्ट लाइन ( i = Fiddle.malloc(1024) ) को भी अलग किया गया, जिससे रिसाव हुआ। प्रोफाइलर ने Fiddle.free को कॉल करने के लिए इसे सही ढंग से बाध्य किया।

यह ध्यान रखना महत्वपूर्ण है कि हम एक आकलन के साथ काम कर रहे हैं। Mwrap डायल सहकर्मी द्वारा आवंटित साझा मेमोरी की निगरानी करता है, और फिर मेमोरी को मुक्त करने की निगरानी करता है। लेकिन अगर आपके पास एक कॉल बिंदु है जो विभिन्न आकारों के मेमोरी ब्लॉकों को आवंटित करता है, तो परिणाम गलत होगा। हमारे पास मूल्यांकन तक पहुंच है: ((total / allocations) * (allocations - frees))

इसके अलावा, रिसाव ट्रैकिंग को सरल बनाने के लिए, म्वरैप, उम्र_टोटल को ट्रैक age_total , जो प्रत्येक मुक्त वस्तु के जीवन काल का योग है, और कॉल बिंदु पर सबसे पुरानी वस्तु के जीवनकाल को भी max_lifespan ट्रैक max_lifespan । यदि age_total / frees बड़ी है, तो कई कचरा संग्रह के बावजूद मेमोरी खपत बढ़ रही है।

शोर कम करने के लिए मेवप्र में कई मददगार हैं। Mwrap.clear सभी आंतरिक संग्रहण को साफ़ कर देगा। Mwrap.quiet {} कोड के ब्लॉक को ट्रैक करने के लिए Mwrap को मजबूर करेगा।

Mwrap की एक और विशिष्ट विशेषता आवंटित और मुक्त किए गए बाइट्स की कुल संख्या की ट्रैकिंग है। स्क्रिप्ट से clear निकालें और उसे चलाएं:

 usage puts "Tracked size: #{(Mwrap.total_bytes_allocated - Mwrap.total_bytes_freed) / 1024}" # RSS: 130804 ObjectSpace size 3032 # Tracked size: 91691 

परिणाम बहुत दिलचस्प है, क्योंकि 130 एमबी के आरएसएस के आकार के बावजूद, मावरप केवल 91 एमबी देखता है। इससे पता चलता है कि हमने अपनी प्रक्रिया को बढ़ा दिया है। मप्र के बिना निष्पादन से पता चलता है कि एक सामान्य स्थिति में प्रक्रिया में 118 एमबी लगती है, और इस साधारण मामले में अंतर 12 एमबी था। आवंटन / मुक्त पैटर्न विखंडन का कारण बना। यह ज्ञान बहुत उपयोगी हो सकता है, कुछ मामलों में, अपुष्ट ग्लिबेल मल्कोक टुकड़े को इतना अधिक संसाधित करता है कि आरएसएस में उपयोग की जाने वाली स्मृति की बहुत बड़ी मात्रा वास्तव में स्वतंत्र है।

क्या Mwrap एक पुराने रेडकारपेट रिसाव को अलग कर सकता है?

अपने लेख में, ओलेग रेडकारपेट में एक बहुत पतले रिसाव को अलग करने के बहुत गहन तरीके से चर्चा करता है। कई विवरण हैं। माप लेना बहुत महत्वपूर्ण है। यदि आप RSS प्रक्रिया के लिए कोई शेड्यूल नहीं बना रहे हैं, तो आप किसी भी लीक से छुटकारा पाने में सक्षम होने की संभावना नहीं है।

चलो एक टाइम मशीन में मिलता है और प्रदर्शित करता है कि इस तरह के लीक के लिए Mwrap का उपयोग करना कितना आसान है।

 def red_carpet_leak 100_000.times do markdown = Redcarpet::Markdown.new(Redcarpet::Render::HTML, extensions = {}) markdown.render("hi") end end GC.start Mwrap.clear red_carpet_leak GC.start # Don't track allocations for this block Mwrap.quiet do report_leaks end 

रेडकारपेट 3.3.2:

 redcarpet.rb:51 growth: 22724224 allocs/frees (500048/400028) redcarpet.rb:62 growth: 4008 allocs/frees (1/0) redcarpet.rb:52 growth: 634 allocs/frees (600007/600000) 

रेडकारपेट 3.5.0:

 redcarpet.rb:51 growth: 4433 allocs/frees (600045/600022) redcarpet.rb:52 growth: 453 allocs/frees (600005/600000) 

यदि आप किसी फ़ाइल में परिणाम लॉग करने के साथ बस इसे Mwrap में पुनरारंभ करके प्रक्रिया को आधी गति से चलाने का जोखिम उठा सकते हैं, तो आप स्मृति लीक की एक विस्तृत श्रृंखला की पहचान कर सकते हैं।

रहस्यमय रिसाव

हाल ही में, रेल को संस्करण 6 में अपडेट किया गया था। सामान्य तौर पर, अनुभव बहुत सकारात्मक था, प्रदर्शन लगभग एक ही रहा। रेल्स 6 में कुछ बहुत अच्छी विशेषताएं हैं जिनका हम उपयोग करेंगे (उदाहरण के लिए Zeitwerk )। रेलों ने टेम्प्लेट के तरीके को बदल दिया, जिससे संगतता के लिए कुछ बदलावों की आवश्यकता थी। अपडेट के कुछ दिनों बाद, हमने साइडकीक कार्य करने वाले के लिए RSS में वृद्धि देखी।

अपने आवंटन ( लिंक ) के कारण स्मृति उपभोग में तेज वृद्धि की सूचना दी:

  source.encode! # Now, validate that the source we got back from the template # handler is valid in the default_internal. This is for handlers # that handle encoding but screw up unless source.valid_encoding? raise WrongEncodingError.new(source, Encoding.default_internal) end begin mod.module_eval(source, identifier, 0) rescue SyntaxError # Account for when code in the template is not syntactically valid; eg if we're using # ERB and the user writes <%= foo( %>, attempting to call a helper `foo` and interpolate # the result into the template, but missing an end parenthesis. raise SyntaxErrorInTemplate.new(self, original_source) end end def handle_render_error(view, e) if e.is_a?(Template::Error) 

पहले तो हम बहुत हैरान थे। हम यह समझने की कोशिश कर रहे थे कि मृग से असंतुष्ट क्यों? शायद वह टूट गया? स्मृति की खपत बढ़ने के साथ, रूबी में ढेर अपरिवर्तित रहे।



हीप में दो मिलियन स्लॉट केवल 78 एमबी (40 बाइट्स प्रति स्लॉट) की खपत हुई। लाइनें और सरणियाँ अधिक स्थान ले सकती हैं, लेकिन यह अभी भी असामान्य स्मृति खपत की व्याख्या नहीं करता है जो हमने देखा था। जब मैंने rbtrace -p SIDEKIQ_PID -e ObjectSpace.memsize_of_all तो इसकी पुष्टि की गई।

स्मृति कहां गई?

Heaptrack

हेपट्रैक लिनक्स के लिए एक ढेर मेमोरी प्रोफाइलर है।

मिलियन वोल्फ ने पूरी तरह से समझाया कि प्रोफाइलर कैसे काम करता है और इसके बारे में कई भाषणों ( 1 , 2 , 3 ) में बात की है। वास्तव में, यह एक बहुत ही कुशल देशी हीप प्रोफाइलर है, जो लिबुनविंड की मदद से , प्रोफाइल अनुप्रयोगों से बैकट्रैक्स एकत्र करता है। यह Valgrind / Massif की तुलना में काफी तेज़ काम करता है और इसमें अस्थायी प्रोफाइलिंग के लिए इसे और अधिक सुविधाजनक बनाने की क्षमता है। इसे पहले से चल रही प्रक्रिया से जोड़ा जा सकता है!

अधिकांश ढेर प्रोफाइलर्स के साथ, जब मॉलॉक परिवार में हर फ़ंक्शन को कॉल किया जाता है, तो हेप्ट्रैक को गिनना चाहिए। यह प्रक्रिया निश्चित रूप से प्रक्रिया को थोड़ा धीमा कर देती है।

मेरी राय में, यहां का आर्किटेक्चर सबसे अच्छा संभव है। प्रोफाइलर को लोड करने के लिए LD_PRELOAD या GDB का उपयोग करके अवरोधन किया जाता है। एक विशेष FIFO फ़ाइल का उपयोग करते हुए , वह जितनी जल्दी हो सके profiled प्रक्रिया से डेटा स्थानांतरित करता है। हेपट्रैक रैपर एक सरल शेल स्क्रिप्ट है जो किसी समस्या को आसान बनाता है। दूसरी प्रक्रिया FIFO से सूचना पढ़ती है और ऑन-द-फ्लाई संपीड़ित ट्रैकिंग डेटा। चूंकि हीप्ट्रैक "चंक्स" के साथ काम करता है, आप प्रोफाइल की शुरुआत के कुछ ही सेकंड बाद प्रोफाइल का विश्लेषण कर सकते हैं, सत्र के ठीक बीच में। बस प्रोफ़ाइल फ़ाइल को किसी अन्य स्थान पर कॉपी करें और Heaptrack GUI लॉन्च करें।

इस GitLab टिकट ने मुझे हीप्ट्राक लॉन्च करने की बहुत संभावना के बारे में बताया। अगर वे इसे चला सकते हैं, तो मैं कर सकता हूं।

हमारा एप्लिकेशन एक कंटेनर में चलता है, और मुझे इसे --cap-add=SYS_PTRACE साथ पुनः आरंभ करने की आवश्यकता है, इससे GDB को ptrace का उपयोग करने की अनुमति मिलती है, जो खुद को इंजेक्ट करने के लिए Heaptrack के लिए आवश्यक है। मुझे गैर- root प्रक्रिया के प्रोफाइल पर root को लागू करने के लिए शेल फ़ाइल के लिए एक छोटी सी हैक की भी आवश्यकता है (हमने एक सीमित खाते के तहत कंटेनर में हमारे डिस्कोर्स एप्लिकेशन को लॉन्च किया है)।

सब कुछ हो जाने के बाद, यह केवल heaptrack -p PID निष्पादित करने और परिणामों के प्रकट होने की प्रतीक्षा करने के लिए बनी हुई है। हीप्ट्राक एक उत्कृष्ट उपकरण निकला, मेमोरी लीक के साथ होने वाली हर चीज को ट्रैक करना बहुत आसान था।



ग्राफ पर, आपको दो cppjieba दिखाई देते हैं, एक cppjieba कारण, दूसरा रूबी में objspace_xmalloc0 कारण।

मुझे cppjieba के बारे में पता था। चीनी भाषा को खंडित करना महंगा है, आपको बड़े शब्दकोशों की आवश्यकता है, इसलिए यह रिसाव नहीं है। लेकिन रूबी में स्मृति आवंटित करने के बारे में क्या, जो अभी भी मुझे नहीं बताता है?



मुख्य लाभ iseq_set_sequence में compile.c से संबंधित है। यह पता चला है कि रिसाव निर्देशों के अनुक्रम के कारण है। इसने मावरप द्वारा खोजे गए रिसाव को साफ किया। इसका कारण mod.module_eval(source, identifier, 0) , जिसने निर्देशों के अनुक्रम बनाए जो स्मृति से हटाए नहीं गए थे।

अगर, पूर्वव्यापी विश्लेषण में, मैंने ध्यान से रूबी से एक ढेर डंप माना, तो मैंने इन सभी IMEMO पर ध्यान दिया होगा, क्योंकि वे इस डंप में शामिल हैं। इन-प्रोसेस डायग्नोस्टिक्स के दौरान वे बस अदृश्य होते हैं।

इस बिंदु से, डिबगिंग बहुत सरल था। मैंने eval मॉड्यूल को सभी कॉल ट्रैक किए और इसका मूल्यांकन किया। मैंने पाया कि हम बार-बार एक बड़े वर्ग के तरीकों को जोड़ रहे हैं। यहाँ हमने जिस बग का सामना किया उसका एक सरलीकृत दृश्य है:

 require 'securerandom' module BigModule; end def leak_methods 10_000.times do method = "def _#{SecureRandom.hex}; #{"sleep;" * 100}; end" BigModule.module_eval(method) end end usage # RSS: 16164 ObjectSpace size 2869 leak_methods usage # RSS: 123096 ObjectSpace size 5583 

रूबी के पास निर्देशों के RubyVM::InstructionSequence दृश्यों को संग्रहीत करने के लिए एक वर्ग है: RubyVM::InstructionSequence । हालांकि, रूबी इन आवरण वस्तुओं को बनाने के लिए बहुत आलसी है, क्योंकि उन्हें अनावश्यक रूप से संग्रहीत करना अक्षम है। Koichi Sasada ने iseq_collector निर्भरता बनाई। यदि हम इस कोड को जोड़ते हैं, तो हम अपनी छुपी हुई मेमोरी पा सकते हैं:

 require 'iseq_collector' puts "#{ObjectSpace.memsize_of_all_iseq / 1024}" # 98747 ObjectSpace.memsize_of_all_iseq 

निर्देशों के प्रत्येक क्रम को उत्प्रेरित करता है, जो प्रक्रिया की मेमोरी खपत को थोड़ा बढ़ा सकता है और कचरा कलेक्टर को थोड़ा और काम दे सकता है।

यदि, उदाहरण के लिए, हम कलेक्टर शुरू करने से पहले और बाद में ISEQs की संख्या की गणना करते हैं, तो हम देखेंगे कि ObjectSpace.memsize_of_all_iseq हमारे काउंटर को शुरू करने के बाद RubyVM::InstructionSequence श्रेणी केवल 0 से 11128 तक बढ़ RubyVM::InstructionSequence (इस उदाहरण में):

 def count_iseqs ObjectSpace.each_object(RubyVM::InstructionSequence).count end 

ये आवरण पूरे विधि के दौरान बने रहेंगे, इन्हें कूड़ा उठाने वाले के पूरे दौरे के साथ जाना होगा। ईमेल टेम्प्लेट ( हॉटफिक्स 1 , हॉटफिक्स 2 ) रेंडर करने के लिए जिम्मेदार वर्ग का पुन: उपयोग करके हमारी समस्या हल की गई थी।

तड़कना

डिबगिंग के दौरान, मैंने एक बहुत ही दिलचस्प उपकरण का उपयोग किया। कुछ साल पहले, टिम बोडी ने मेमोरी लीक का विश्लेषण करने के लिए VMWare द्वारा उपयोग किए गए एक आंतरिक उपकरण को बाहर निकाला और अपना कोड खुला बनाया। यहाँ इस बारे में एकमात्र वीडियो है जिसे मैं खोजने में कामयाब रहा: https://www.youtube.com/watch?v=EZ2n3kGtVVk । अधिकांश समान उपकरणों के विपरीत, इस एक का निष्पादन योग्य प्रक्रिया पर कोई प्रभाव नहीं पड़ता है। यह बस मुख्य डंप की फ़ाइलों पर लागू किया जा सकता है, जबकि ग्लिबक का उपयोग एक आवंटनकर्ता के रूप में किया जाता है (जेमलॉक / टीसीएमलोके, आदि के लिए कोई समर्थन नहीं है)।

चैप के साथ, मेरे पास जो लीक है, उसका पता लगाना बहुत आसान है। कुछ वितरणों में एक चैप बाइनरी है, लेकिन आप इसे आसानी से स्रोत कोड से संकलित कर सकते हैं। वह बहुत सक्रिय रूप से समर्थित है।

 # 444098 is the `Process.pid` of the leaking process I had sudo gcore -p 444098 chap core.444098 chap> summarize leaked Unsigned allocations have 49974 instances taking 0x312f1b0(51,573,168) bytes. Unsigned allocations of size 0x408 have 49974 instances taking 0x312f1b0(51,573,168) bytes. 49974 allocations use 0x312f1b0 (51,573,168) bytes. chap> list leaked ... Used allocation at 562ca267cdb0 of size 408 Used allocation at 562ca267d1c0 of size 408 Used allocation at 562ca267d5d0 of size 408 ... chap> summarize anchored .... Signature 7fbe5caa0500 has 1 instances taking 0xc8(200) bytes. 23916 allocations use 0x2ad7500 (44,922,112) bytes. 

चैप अलग-अलग मेमोरी के स्थानों की खोज के लिए हस्ताक्षरों का उपयोग कर सकता है और यह GDB को पूरक कर सकता है। रूबी में डिबगिंग करते समय, यह निर्धारित करने में बहुत मदद मिल सकती है कि प्रक्रिया किस मेमोरी का उपयोग कर रही है। यह कुल इस्तेमाल की गई मेमोरी को दिखाता है, कभी-कभी ग्लिबेक मालॉक इतना टुकड़ा कर सकता है कि इस्तेमाल की गई मात्रा वास्तविक आरएसएस से बहुत अलग हो सकती है। आप चर्चा पढ़ सकते हैं: फ़ीचर # 14759: [PATCH] gl_c malloc के लिए M_ARENA_MAX सेट करें - रूबी मास्टर - रूबी अंक ट्रैकिंग सिस्टम । चैप सभी उपयोग की गई मेमोरी को सही ढंग से गिनने और उसके आवंटन का गहराई से विश्लेषण करने में सक्षम है।

इसके अलावा, चैप को लीक और स्वचालित रूप से ऐसी असेंबली का पता लगाने के लिए वर्कफ़्लोज़ में एकीकृत किया जा सकता है।

काम का पालन करें

इस डिबगिंग राउंड ने मुझे हमारे सहायक टूलकिट से संबंधित कुछ प्रश्न उठाए:

• मैं हेपट्रैक में रूबी से कॉल स्टैक फ़्रेम कैप्चर करने के लिए समर्थन करना चाहूंगा। मिलियन भी इस में रुचि रखते हैं: 412929 - क्या हम रूबी भूमि से एक फ्रेम ले सकते हैं?
  
• मैं रूबी को व्यापक नैदानिक ​​क्षमताओं का समर्थन करना चाहूंगा: https://bugs.ruby-lang.org/issues/16245
  
• मैं चाहूंगा कि मेवाप को ठेस पहुंचाने में थोड़ी आसानी हो। यहाँ पढ़ें

सारांश

बहुत जटिल मेमोरी लीक को डिबग करने के लिए हमारा आज का टूलकिट 4 साल पहले की तुलना में बहुत बेहतर है! विकास और संचालन के दौरान उत्पन्न होने वाली स्मृति समस्याओं को हल करने के लिए Mwrap, Heaptrack और chap बहुत शक्तिशाली उपकरण हैं।

यदि आप रूबी में एक सरल स्मृति रिसाव के लिए शिकार कर रहे हैं, तो मैं अपने 2015 के लेख को पढ़ने की सलाह देता हूं , अधिकांश भाग के लिए यह प्रासंगिक है।

मुझे आशा है कि अगली बार जब आप किसी जटिल देशी स्मृति रिसाव को डीबग करना शुरू करेंगे तो आपको यह आसान लगेगा।