Erlang 21 - 11. Profiling

11 प्रोफाइलिंग




erlang

11 प्रोफाइलिंग

11.1 प्रदर्शन के बारे में अनुमान न करें - प्रोफ़ाइल

यहां तक ​​कि अनुभवी सॉफ्टवेयर डेवलपर्स अक्सर गलत अनुमान लगाते हैं कि उनके कार्यक्रमों में प्रदर्शन की अड़चनें कहां हैं। इसलिए, अपने कार्यक्रम को देखने के लिए देखें कि प्रदर्शन की अड़चनें कहाँ हैं और उन्हें अनुकूलित करने पर ध्यान केंद्रित करें।

अड़चन / OTP में अड़चन खोजने में मदद करने के लिए कई उपकरण शामिल हैं:

  • fprof सबसे विस्तृत जानकारी प्रदान करता है कि प्रोग्राम का समय कहाँ बिताया जाता है, लेकिन यह प्रोग्राम को काफी धीमा कर देता है।

  • eprof कार्यक्रम में उपयोग किए जाने वाले प्रत्येक फ़ंक्शन की समय की जानकारी प्रदान करता है। कोई कॉल ग्राफ़ उत्पन्न नहीं होता है, लेकिन eprof कार्यक्रम पर काफी कम प्रभाव पड़ता है जो इसे प्रोफाइल करता है।

    यदि प्रोग्राम बहुत बड़ा है, तो fprof या eprof द्वारा प्रोफाइल किया जा सकता है, तो cprof का उपयोग कोड भागों का पता लगाने के लिए किया जा सकता है जो कि fprof या eprof का उपयोग करके अधिक अच्छी तरह से profiled eprof

  • cprof सबसे हल्का उपकरण है, लेकिन यह केवल फ़ंक्शन आधार पर (सभी प्रक्रियाओं के लिए, प्रति प्रक्रिया नहीं) निष्पादन निष्पादन प्रदान करता है।

  • dbg जेनेरिक इरलैंग ट्रेसिंग फ्रंटेंड है। timestamp या cpu_timestamp विकल्पों का उपयोग करके इसका उपयोग समय के लिए किया जा सकता है कि लाइव सिस्टम कॉल में कितने समय तक काम करता है।

  • lcnt का उपयोग Erlang Run-Time System के इंटरनल लॉकिंग मैकेनिज़्म में lcnt खोजने के लिए किया जाता है। यह प्रक्रिया, पोर्ट, ईटीएस टेबल और अन्य संस्थाओं के बीच बातचीत में अड़चन की तलाश में उपयोगी है जो समानांतर में चलाए जा सकते हैं।

उपकरण में आगे Tools वर्णित हैं।

Erlang / OTP के बाहर कई खुले स्रोत उपकरण भी हैं जिनका उपयोग प्रोफाइलिंग में मदद करने के लिए किया जा सकता है। उनमें से कुछ हैं:

  • erlgrind का उपयोग kcachegrind में फिटर डेटा की कल्पना करने के लिए किया जा सकता है।
  • eflame का एक विकल्प है जो प्रोफाइलिंग आउटपुट को एक लौ के रूप में प्रदर्शित करता है।
  • recon एर्लांग प्रोफाइलिंग और डीबगिंग टूल्स का एक संग्रह है। यह टूल Erlang in Anger नामक एक ई-बुक के साथ आता है जिसे Erlang in Anger कहा जाता है।

11.2 मेमोरी प्रोफाइलिंग

eheap_alloc: Cannot allocate 1234567890 bytes of memory (of type "heap").

उपरोक्त स्लोगन Erlang को समाप्त करने के लिए अधिक सामान्य कारणों में से एक है। अज्ञात कारणों से Erlang Run-Time System उपयोग के लिए मेमोरी आवंटित करने में विफल रहा। जब ऐसा होता है तो एक क्रैश डंप उत्पन्न होता है जिसमें सिस्टम की स्थिति के बारे में जानकारी होती है क्योंकि यह mmeory से बाहर चला गया था। उपयोग किया जा रहा है कि मेमोरी का एक दृश्य प्राप्त करने के लिए crashdump_viewer का उपयोग करें। बड़े ढेर या कई संदेश, बड़ी ईटी टेबल आदि प्रक्रियाओं के लिए देखें।

किसी रनिंग सिस्टम में मेमोरी के उपयोग को देखते समय सूचना प्राप्त करने का सबसे बुनियादी कार्य है erlang:memory() । यह सिस्टम का वर्तमान मेमोरी उपयोग लौटाता है। instrument(3) का उपयोग अधिक विस्तृत ब्रेकडाउन प्राप्त करने के लिए किया जा सकता है जहां मेमोरी का उपयोग किया जाता है।

प्रक्रियाओं, बंदरगाहों और ईटीएस टेबल को उनके संबंधित सूचना कार्यों का उपयोग करके निरीक्षण किया जा सकता है, अर्थात् erlang:process_info/2 , erlang:port_info/2 और ets:info/1

कभी-कभी सिस्टम एक ऐसी स्थिति में प्रवेश कर सकता है जहां erlang:memory(total) से रिपोर्ट की गई मेमोरी erlang:memory(total) ओएस द्वारा रिपोर्ट की गई मेमोरी से बहुत अलग है। एर्लैंग रन-टाइम सिस्टम के भीतर आंतरिक विखंडन के कारण यह हो सकता है। मेमोरी कैसे आवंटित की जाती है, इसके बारे में डेटा erlang:system_info(allocator) का उपयोग करके पुनर्प्राप्त किया जा सकता है। उस फ़ंक्शन से जो डेटा आपको मिलता है वह बहुत कच्चा है और पढ़ने के लिए बहुत उपयुक्त नहीं है। recon_alloc का उपयोग system_info सांख्यिकी काउंटर से उपयोगी जानकारी निकालने के लिए किया जा सकता है।

11.3 बड़े सिस्टम

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

एक बड़ी प्रणाली के लिए, आप पूरे सिस्टम पर प्रोफाइलिंग टूल नहीं चलाना चाहते हैं। इसके बजाय आप केंद्रीय प्रक्रियाओं और मॉड्यूल पर ध्यान केंद्रित करना चाहते हैं, जो निष्पादन के एक बड़े हिस्से के लिए योगदान करते हैं।

कुछ ऐसे उपकरण भी हैं जिनका उपयोग अधिक या कम ओवरहेड के साथ पूरे सिस्टम का दृश्य प्राप्त करने के लिए किया जा सकता है।

  • observer एक GUI टूल है जो रिमोट नोड से कनेक्ट हो सकता है और रनिंग सिस्टम के बारे में कई तरह की जानकारी प्रदर्शित कर सकता है।
  • etop एक कमांड लाइन उपकरण है जो दूरस्थ नोड्स से कनेक्ट हो सकता है और UNIX टूल टॉप शो के समान सूचना प्रदर्शित कर सकता है।
  • msacc उपयोगकर्ता को यह देखने की अनुमति देता है कि msacc रन-टाइम सिस्टम क्या कर रहा है। बहुत कम ओवरहेड है, जो कि अधिक दानेदार प्रोफाइलिंग शुरू करने के लिए कुछ विचार प्राप्त करने के लिए भारी भारित प्रणालियों में चलाने के लिए उपयोगी बनाता है।

11.4 क्या देखना है

प्रोफाइलिंग गतिविधि से परिणाम फ़ाइल का विश्लेषण करते समय, उन कार्यों की तलाश करें जिन्हें कई बार कहा जाता है और लंबे समय तक "स्वयं" निष्पादन समय होता है (कॉल अन्य कार्यों को छोड़कर समय)। ऐसे कार्य जिन्हें बहुत बार कहा जाता है, वे भी दिलचस्प हो सकते हैं, क्योंकि अक्सर छोटी चीजें भी जोड़ सकते हैं यदि अक्सर दोहराया जाए। अपने आप से भी पूछें कि इस समय को कम करने के लिए आप क्या कर सकते हैं। निम्नलिखित प्रश्न अपने आप से पूछने के लिए उपयुक्त प्रकार हैं:

  • क्या फ़ंक्शन कहा जाता है की संख्या को कम करना संभव है?
  • यदि परीक्षणों के क्रम को बदल दिया जाए तो क्या कोई परीक्षण कम बार चलाया जा सकता है?
  • क्या कोई निरर्थक परीक्षण हटाया जा सकता है?
  • क्या कोई गणना की गई अभिव्यक्ति हर बार एक ही परिणाम देती है?
  • क्या ऐसा करने के अन्य तरीके हैं जो समकक्ष और अधिक कुशल हैं?
  • क्या किसी अन्य आंतरिक डेटा प्रतिनिधित्व का उपयोग चीजों को अधिक कुशल बनाने के लिए किया जा सकता है?

ये सवाल हमेशा जवाब देने के लिए तुच्छ नहीं होते हैं। अपने सिद्धांत का समर्थन करने और चीजों को धीमा करने से बचने के लिए कुछ बेंचमार्क की आवश्यकता हो सकती है यदि आपका सिद्धांत गलत है। विवरण के लिए, Benchmarking देखें।

11.5 उपकरण

fprof

fprof प्रत्येक फ़ंक्शन के लिए निष्पादन समय को मापता है, दोनों का समय, अर्थात, किसी फ़ंक्शन ने अपने निष्पादन के लिए कितना समय उपयोग किया है, और संचित समय, अर्थात, जिसे फ़ंक्शन भी कहा जाता है। मान प्रति प्रक्रिया प्रदर्शित होते हैं। आपको यह भी पता चलता है कि प्रत्येक फ़ंक्शन को कितनी बार बुलाया गया है।

fprof रनटाइम प्रदर्शन प्रभाव को कम करने के लिए फ़ाइल पर ट्रेस पर आधारित है। fprof का उपयोग करना केवल कुछ लाइब्रेरी फ़ंक्शंस को कॉल करने का विषय है, टूल्स में fprof मैनुअल पेज देखें।

eprof

eprof Erlang trace_info BIF पर आधारित है। eprof दिखाता है कि प्रत्येक प्रक्रिया द्वारा कितना समय का उपयोग किया गया है, और इस समय किस फ़ंक्शन में कॉल किया गया है। समय को कुल समय और निरपेक्ष समय के प्रतिशत के रूप में दिखाया गया है। अधिक जानकारी के लिए, टूल में eprof मैन्युअल पेज देखें।

cprof

सुविधाओं के संबंध में fprof और cover के बीच में कुछ है। यह गणना करता है कि प्रत्येक मॉड्यूल के आधार पर कार्यक्रम चलने पर प्रत्येक फ़ंक्शन को कितनी बार कहा जाता है। cprof में कम परफॉर्मेंस डिग्रेडेशन इफ़ेक्ट है ( fprof साथ तुलना में) और इसे किसी भी मॉड्यूल को प्रोफाइल ( cover की तुलना में) से fprof करने की ज़रूरत नहीं है। अधिक जानकारी के लिए, टूल में cprof मैनुअल पेज देखें।

टूल सारांश

साधन परिणाम परिणाम का आकार कार्यक्रम निष्पादन समय पर प्रभाव कॉल की रिकॉर्ड संख्या रिकॉर्ड निष्पादन समय रिकॉर्ड्स द्वारा कॉल किया गया रिकॉर्ड्स कचरा संग्रह
fprof स्क्रीन / फ़ाइल के लिए प्रति प्रक्रिया विशाल महत्वपूर्ण मंदी हाँ कुल और अपना हाँ हाँ
eprof स्क्रीन / फ़ाइल के प्रति प्रक्रिया / कार्य मध्यम छोटी मंदी हाँ केवल कुल नहीं नहीं
cprof प्रति मॉड्यूल कॉलर के लिए छोटा छोटी मंदी हाँ नहीं नहीं नहीं

तालिका 11.1: टूल सारांश

dbg

dbg एक जेनेरिक Erlang ट्रेस टूल है। timestamp या cpu_timestamp विकल्पों का उपयोग करके यह एक सटीक उपकरण के रूप में इस्तेमाल किया जा सकता है कि किसी विशिष्ट प्रक्रिया के लिए फ़ंक्शन कॉल में कितना समय लगता है। यह समझने में बहुत उपयोगी हो सकता है कि एक भारी भरी हुई व्यवस्था में समय कहाँ व्यतीत किया जाता है क्योंकि बहुत छोटा होने के लिए जो कुछ है, उसके दायरे को सीमित करना संभव है। अधिक जानकारी के लिए, रनटाइम टूल्स में dbg मैनुअल पेज देखें।

lcnt

lcnt समानांतर में चलने वाली lcnt संस्थाओं की प्रोफाइल प्रोफाइल के लिए उपयोग किया जाता है। उदाहरण के लिए यदि आपके पास एक प्रक्रिया है जिसे सिस्टम में अन्य सभी प्रक्रियाओं के साथ बातचीत करने की आवश्यकता है (शायद इसका कुछ वैश्विक कॉन्फ़िगरेशन है), तो lcnt का उपयोग यह पता लगाने के लिए किया जा सकता है कि क्या उस प्रक्रिया के साथ बातचीत एक समस्या है।

Erlang रन-टाइम सिस्टम में कई शेड्यूलर होने पर सिस्टम समानांतर में ही चलाए जाते हैं। इसलिए lcnt कई कोर पर कई अनुसूचियों का उपयोग कर सिस्टम पर अधिक विवाद बिंदु (और इस प्रकार अधिक उपयोगी होगा) दिखाएगा।

अधिक जानकारी के लिए, टूल्स में lcnt मैनुअल पेज देखें।

11.6 बेंचमार्किंग

बेंचमार्किंग का मुख्य उद्देश्य यह पता लगाना है कि किसी दिए गए एल्गोरिदम या फ़ंक्शन का कौन सा कार्यान्वयन सबसे तेज़ है। बेंचमार्किंग एक सटीक विज्ञान से दूर है। आज के ऑपरेटिंग सिस्टम आम तौर पर पृष्ठभूमि कार्यों को चलाते हैं जिन्हें बंद करना मुश्किल है। कैश और कई सीपीयू कोर बेंचमार्किंग की सुविधा नहीं देते हैं। बेंचमार्किंग के समय एकल-उपयोगकर्ता मोड में UNIX कंप्यूटर चलाना सबसे अच्छा होगा, लेकिन यह आकस्मिक परीक्षण के लिए कम से कम कहने के लिए असुविधाजनक है।

बेंचमार्क दीवार-घड़ी समय या सीपीयू समय को माप सकते हैं।

  • timer:tc/3 उपाय दीवार घड़ी समय। दीवार-घड़ी के समय के साथ लाभ यह है कि मैं / ओ, स्वैपिंग, और ऑपरेटिंग सिस्टम कर्नेल में अन्य गतिविधियों को माप में शामिल किया गया है। नुकसान यह है कि माप बहुत भिन्न होते हैं। आमतौर पर बेंचमार्क को कई बार चलाना और सबसे कम समय को ध्यान में रखना सबसे अच्छा होता है, जो कि न्यूनतम समय होता है जो कि परिस्थितियों में सबसे अच्छा हो सकता है।
  • statistics/1 तर्क runtime उपायों के साथ एर्लांग आभासी मशीन में खर्च सीपीयू समय। CPU समय के साथ लाभ यह है कि परिणाम रन से चलाने के लिए अधिक सुसंगत हैं। नुकसान यह है कि ऑपरेटिंग सिस्टम कर्नेल (जैसे स्वैपिंग और आई / ओ) में बिताया गया समय शामिल नहीं है। इसलिए, यदि कोई I / O (फ़ाइल या सॉकेट) शामिल है, तो CPU समय को मापना भ्रामक है।

दीवार-घड़ी माप और सीपीयू समय माप दोनों करना शायद एक अच्छा विचार है।

कुछ अंतिम सलाह:

  • दोनों माप प्रकारों की ग्रैन्युलैरिटी अधिक हो सकती है। इसलिए, सुनिश्चित करें कि प्रत्येक व्यक्तिगत माप कम से कम कई सेकंड तक रहता है।
  • परीक्षण को उचित बनाने के लिए, प्रत्येक नए परीक्षण को अपने स्वयं के, नई बनाई गई एर्लांग प्रक्रिया में चलाना है। अन्यथा, यदि सभी परीक्षण एक ही प्रक्रिया में चलते हैं, तो बाद के परीक्षण बड़े ढेर आकारों के साथ शुरू होते हैं और इसलिए संभवतः कम कचरा संग्रह करते हैं। प्रत्येक परीक्षण के बीच एरलांग एमुलेटर को फिर से शुरू करने पर भी विचार करें।
  • यह मत समझो कि कंप्यूटर आर्किटेक्चर एक्स पर दिए गए एल्गोरिदम का सबसे तेज़ कार्यान्वयन कंप्यूटर आर्किटेक्चर वाई पर भी सबसे तेज़ है।