2017-11-10 50 views
12

के साथ साइडकीक वर्कर मेमोरी लीक डीबगिंग तो, मुझे अपने साइडकीक वर्कर में मेमोरी लीक मिल गई है। मेरे पास केवल इस कार्यकर्ता कार्य के लिए एक कतार के साथ एक कार्यकर्ता सर्वर है, जो एक सप्ताह में लगभग 10 जी आरएसएस तक पहुंच जाता है।jemalloc

मैंने इसे केवल 1 कार्यकर्ता थ्रेड और वॉयला के साथ स्थानीय रूप से पुन: उत्पन्न करने की कोशिश की - मुझे एक रात में 200 एम से 1 जी तक, 1 कार्य/मिनट संसाधित किया जाता है। स्वाभाविक रूप से, मैं जानना चाहता हूं कि लीकिंग क्या है, इसलिए मैं आरएसएस, heap_live_slots और heap_free_slots भी लॉगिंग कर रहा हूं। जब मैं साजिश के परिणाम देखता हूं तो मैं RSS विकास को देख सकता हूं जबकि live and free slots यादृच्छिक रूप से उतार-चढ़ाव करता है लेकिन अच्छी तरह परिभाषित और स्थिर सीमाओं में, जबकि उनका योग स्थिर रहता है।

इस बिंदु पर मैं इस निष्कर्ष पर पहुंचा हूं कि रिसाव की संभावना रूबी कोड में नहीं बल्कि कुछ मूल विस्तार में होती है। इसलिए मैं RVM के माध्यम से Jemalloc समर्थन के साथ गहरे लाल रंग का पुनः स्थापित: rvm reinstall 2.4.2 --with-jemalloc

तब मैं MALLOC_CONF की स्थापना:

export MALLOC_CONF='prof_leak:true,lg_prof_sample:0,prof_final:true,stats_print:true'

और Sidekiq ऊपर आग। हाल में 1 कार्यकर्ता धागा के साथ शुरू किया Sidekiq 200M आरएसएस के बारे में लायक है, लेकिन जब मैं Ctrl + C दबाएं और jemalloc के आँकड़े उत्पादन को देखो मैं कुछ पूरी तरह से अलग देखें:

Arenas: 32 
Quantum size: 16 
Page size: 4096 
Maximum thread-cached size class: 32768 
Allocated: 34056, active: 61440, metadata: 2949272, resident: 2981888, mapped: 6352896, retained: 2035712 

क्या? 6 एम मैप किया गया? यह सच नहीं हो सकता है। प्रतीक्षा के बाद

2.4.2 :001 > arr = [] 
=> [] 
2.4.2 :002 > loop do 
2.4.2 :003 > arr << 'a'*10000000 
2.4.2 :004?> sleep 1 
2.4.2 :005?> end 

तक आईआरबी प्रक्रिया चढ़ते को 1G आरएसएस के बारे में मैं प्रक्रिया को रोकने के ... और बिल्कुल वैसा ही संख्या देखें: तो मैं आईआरबी शुरू करने और निम्न उपाय अपनाते हैं। हो सकता है कि कॉल ग्राफ़ को विज़ुअलाइज़ करने से मुझे यह समझने में मदद मिलेगी कि क्या हो रहा है?

jeprof --show_bytes --pdf `which ruby` jeprof.10536.0.f.heap > ruby.pdf 

Using local file /home/mhi/.rvm/rubies/ruby-2.4.2/bin/ruby. 
Using local file jeprof.10536.0.f.heap. 
No nodes to print 

तो कुछ स्पष्ट रूप से गलत है, और यही मुझे मदद करने में मदद की ज़रूरत है। https://pastebin.com/RiMLtqA6

युपीडी:

यहाँ jemalloc स्टेट से पूर्ण उत्पादन है।

तो मैं सभी देशी-विस्तार से संबंधित रत्न को नवीनीकृत किया है, यहाँ bundle exec ruby -e 'puts Gem.loaded_specs.values.select{ |i| !i.extensions.empty? }.map{ |i| "#{i.name} #{i.version}" }' के उत्पादन में है:

io-console 0.4.6 
nokogiri 1.8.1 
bcrypt 3.1.11 
debug_inspector 0.0.3 
binding_of_caller 0.7.2 
json 2.1.0 
capybara-webkit 1.14.0 
damerau-levenshtein 1.3.0 
unf_ext 0.0.7.4 
eventmachine 1.2.5 
ffi 1.9.18 
kgio 2.11.0 
msgpack 1.1.0 
mysql2 0.4.9 
rainbow 2.2.2 
raindrops 0.18.0 
rbtrace 0.4.8 
stackprof 0.2.10 
therubyracer 0.12.3 
unicode 0.4.4.4 
unicorn 5.3.0 

एक ही परिणाम: RSS, Memory slots

+1

हमें इसके आउटपुट की आवश्यकता है: 'बंडल exec ruby ​​-e' Gem.loaded_specs.values.select {| i | ! I.extensions.empty? } .map {| i | "# {i.name} # {i.version}"} '' –

+1

आप हाल ही में रूबी पर हैं। सुनिश्चित करें कि आप सभी मूल एक्सटेंशन के नवीनतम संस्करणों का उपयोग कर रहे हैं। –

+0

@ माइकपेरहम ठीक है, हाँ, देशी एक्सटेंशन के साथ पुराने पुराने रत्न हैं, मैं उन्हें अपडेट करूँगा और देख सकता हूं कि यह स्थिति में मदद करता है या नहीं। सलाह के लिए धन्यवाद! – Roman

उत्तर

2

Ruby 2.4.2 has a known issue with jemalloc

इस मुद्दे को एक महीने पहले बंद कर दिया गया था, लेकिन मुझे नहीं पता कि आप जिस पैकेज का उपयोग कर रहे हैं वह पैच किया गया है ... वास्तव में, मुझे नहीं लगता कि पैच अभी तक जारी किया गया था। यह संभावना है कि सभी jemalloc स्टेट डेटा अप्रासंगिक है।

इसके अलावा, यह X-Y question जैसा लगता है (आप jemalloc के बारे में पूछ रहे हैं, जबकि आप शायद स्मृति "रिसाव" का समाधान चाहते हैं)।

देशी कोड (हालांकि एक अलग संभावना) में मेमोरी रिसाव ग्रहण करने से पहले, मैं विचार करता हूं कि कार्य का दायरा कचरा कलेक्टर को कैसे प्रभावित कर सकता है और दोनों दायरे और किसी भी दीर्घकालिक चर को कम करने का प्रयास करता है।

उदाहरण के लिए, यदि आपके काम के लिए एक Proc है, यह वैश्विक क्षेत्र है, जिसका अर्थ है कि कुछ चर हमेशा के लिए जीना हो सकता है करने के लिए बाध्य किया जा सकता है ...

एक समारोह में कार्य संलग्न की कोशिश करो और कि कोई भी सुनिश्चित कर लें एक बार कार्य पूरा होने के बाद चर के संदर्भ दिए जाते हैं।

+0

इसे 2.3.0 के साथ आजमाया - एक ही परिणाम मिला। मुझे क्या लगता है कि यह मूल कोड मुद्दा है यह तथ्य है कि रूबी ढेर में लाइव ऑब्जेक्ट्स गिनती समय के साथ नहीं बढ़ती है। – Roman

+0

@Roman, क्या आपने अपडेट की गई 'कॉन्फ़िगरेशन' फ़ाइल के साथ रूबी 2.4.2 का उपयोग करने का प्रयास किया जो बग रिपोर्ट बंद कर दिया? यह आपको 'jemalloc' का उपयोग करने की अनुमति देनी चाहिए। – Myst

+0

@ रोमन, कृपया ध्यान दें कि वस्तुओं की एक ही संख्या होने पर एक पूर्ण संकेत नहीं हो सकता है। उदाहरण के लिए, यदि आपके पास कभी बढ़ती हुई स्ट्रिंग है, तो यह केवल एक वस्तु है जो हमेशा के लिए रहती है और लगातार बढ़ती जा सकती है। संख्याएं हमेशा ऑब्जेक्ट्स नहीं होती हैं, इसलिए संख्याओं की एक सरणी एक और वस्तु हो सकती है जो एक डरावनी आकार में बढ़ सकती है। – Myst