जाओ (लैंग) मेमोरी उपयोग: आरएसआईजेई बढ़ रहा है और 13 9 जीबी का वीएसआईजेई?

Question

मैं गो में अपना पहला वेबसर्वर/वेबसाइसेस प्रोग्राम लिख रहा हूं और मुझे एहसास हुआ कि आरएसआईजेई (जैसा कि कमांड लाइन प्रोग्राम "टॉप" द्वारा दिखाया गया है) मेरे वेब सर्विसेज के लिए एक ही अनुरोध को दोहराने के बाद बढ़ता है। क्या इसका मतलब है कि एक स्मृति रिसाव है?

मैंने यह भी देखा कि मेरे शीर्ष ऐप और "टॉप" पर जाने की प्रक्रिया में 13 9 जीबी (उनमें से दोनों बिल्कुल आकार) का VSIZE है। क्या यह सामान्य है?

मैं जाओ 1.1.2 का उपयोग कर रहा ओएस एक्स पर 10.8

कई धन्यवाद

Answer 1

बिग VSIZE तुम सच में भौतिक स्मृति का उपयोग कर रहे मतलब यह नहीं है; इसके बारे में चिंता नहीं करेंगे।

एक अनुरोध के बाद बढ़ते आरएसआईजेई भी चिंताजनक नहीं है। रैम को कचरा संग्रह द्वारा पुनः प्राप्त किया जाता है, जिसकी लागत सीपीयू चक्र होती है, इसलिए गो और अन्य जीसीडी भाषाएं तब तक कई अनुरोधों की प्रतीक्षा करती हैं जब तक उन्हें संग्रह चलाने के लिए रैम मुक्त नहीं किया जाता है (या कम से कम रैम आवंटित किए जाने तक)। कम संग्रह => कम CPU समय बिताया।

सामान्य ज्ञान में लीक दुर्लभ हैं क्योंकि जीसी अंततः मुक्त स्मृति होनी चाहिए जिसके लिए आप संदर्भ नहीं ले रहे हैं। यदि आपके पास बफर हैं जो आवश्यकतानुसार बढ़ते हैं लेकिन कभी कम नहीं होते हैं, तो उनके पास रिसाव जैसा प्रभाव हो सकता है, और यदि आप गलती से स्मृति का संदर्भ रखते हैं जो वास्तव में मर चुका है तो आपको समस्या हो सकती है। लेकिन जब तक प्रक्रिया हमेशा के लिए बढ़ती रहती है, तो मुझे नहीं लगता कि आपको यह समस्या हो रही है।

यहां जाने के लिए कुछ मेमोरी-प्रबंधन युक्तियां दी गई हैं; कुछ अप्रत्यक्ष रूप से अन्य भाषाओं पर भी लागू होते हैं:

• आपको अक्सर चिंता करने की आवश्यकता नहीं है। संग्रह अक्सर तेज़ होता है और आपके डेटा के आकार के सापेक्ष आपके पास अक्सर खेलने के लिए बहुत सी रैम होती है। इससे पहले कि आप गोता लगाएँ, सुनिश्चित करें कि हल करने में कोई समस्या है। :)
• runtime.ReadMemStats(ms) आप बता सकते हैं कि कितनी देर तक अपने कार्यक्रम, जीसी में बिताया है कि आप कितना आवंटन रहे हैं अन्य उपयोगी जानकारी के बहुत सारे के साथ (http://golang.org/pkg/runtime/ पर runtime मॉड्यूल डॉक्स देखें)
• आप बहुत ज्यादा खर्च कर रहे हैं जीसी में समय और पता नहीं क्यों, ज्ञापन अगला कदम है; कार्यक्रम को शामिल करने का एक पूरा उदाहरण एक वैकल्पिक-मेमप्रोफाइल ध्वज गो ब्लॉग पर है: http://blog.golang.org/profiling-go-programs
• सामान्य रूप से, आप अनियंत्रित आवंटन को कम करके जीसी को कम करते हैं, विशेष रूप से बड़ी वस्तुओं के आवंटन (पूरे HTTP प्रतिक्रियाओं वाले बफर धारक) कहते हैं। कभी-कभी आपके प्रोग्राम को गंदे किए बिना ऐसा करने के प्राकृतिक तरीके होते हैं - उदाहरण के लिए, आप प्रत्येक बार आवंटित करने के बजाय लूप के कई पुनरावृत्तियों में किसी ऑब्जेक्ट का पुन: उपयोग कर सकते हैं। अन्य बार, आप रीसायकल पुराने ऑब्जेक्ट्स बनाने के बजाय पुरानी ऑब्जेक्ट्स कर सकते हैं; मानक sync.Pool पैकेज उसमें मदद करता है, और रीसाइक्लिंग का एक अच्छा सामान्य विवरण है (sync.Pool से पहले मानक था) on the CloudFlare blog।

मुबारक हो जाओ!