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

लोकप्रिय प्रोफाइलर

यदि आप एक मौलिक रूप से भिन्न जानते हैं - तो टिप्पणियों में इसके बारे में लिखें। इस बीच, इन 4 पर विचार करें:

मैं

अच्छे पुराने UNIX प्रोफाइलर, जो किर्क मैककिक के अनुसार, बिल जॉय द्वारा बीएसडी उप प्रणालियों के प्रदर्शन का विश्लेषण करने के लिए लिखे गए थे। वास्तव में, प्रोफाइलर को संकलक द्वारा "प्रदान" किया जाता है - इसे प्रत्येक फ़ंक्शन के अंत में और शुरुआत में ब्रेकप्वाइंट सेट करना होगा। इन दोनों बिंदुओं के बीच का अंतर इसके निष्पादन का समय होगा।
यह ध्यान दिया जाना चाहिए कि इस मामले में gprof बिल्कुल "जानता है" कि कितनी बार प्रत्येक फ़ंक्शन को बुलाया गया था। और यद्यपि यह कुछ स्थितियों में आवश्यक हो सकता है, लेकिन इसका एक नकारात्मक प्रभाव भी है - माप से ओवरहेड तुलनीय या फिर फ़ंक्शन से भी अधिक हो सकता है। इसलिए, उदाहरण के लिए, जब C ++ कोड को संकलित किया जाता है, तो इनलाइन में अग्रणी अनुकूलन का उपयोग किया जाता है।
एक तरह से या किसी अन्य, लेकिन पहले से चल रहे कार्यक्रमों के साथ gprof काम नहीं करता है।

द्वितीय। Callgrind

Callgrind, Valgrind का एक हिस्सा है, जो गतिशील कोड विश्लेषण के लिए उपकरण बनाने के लिए एक उत्कृष्ट ढांचा है। Valgrind सैंडबॉक्स प्रोग्राम चलाता है, वास्तव में वर्चुअलाइजेशन का उपयोग करता है। कॉलग्रिंड कॉल और रिट जैसे निर्देशों पर ब्रेकप्वाइंट के आधार पर प्रोफाइलिंग करता है। यह एक नियम के रूप में, विश्लेषण किए गए कोड को 5 से 20 गुना तक धीमा कर देता है। इस प्रकार, रनटाइम में बड़े डेटा पर विश्लेषण के लिए, यह आमतौर पर उपयुक्त नहीं है।
हालांकि, उपकरण बहुत लोकप्रिय है, और एक साधारण कॉल ग्राफ़ प्रारूप उत्कृष्ट विज़ुअलाइज़ेशन टूल द्वारा समर्थित है, उदाहरण के लिए, kcachegrind।

तृतीय। OProfile

OProfile Linux सिस्टम के लिए एक सिस्टम-वाइड प्रोफाइलर है, जो कम ओवरहेड पर सभी रनिंग कोड को प्रोफाइल करने में सक्षम है।

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

OProfile का नया संस्करण 0.9.8

संस्करण 0.9.7 और उससे पहले के लिए, प्रोफाइलर में डेटा को इकट्ठा करने के लिए एक कर्नेल ड्राइवर और एक डेमन शामिल था। संस्करण 0.9.8 के बाद से, इस विधि को लिनक्स कर्नेल प्रदर्शन घटनाओं के उपयोग से बदल दिया गया है (एक कर्नेल 2.6.31 या नए की आवश्यकता है)। रिलीज 0.9.8 में 'ऑपेराफ' कार्यक्रम भी शामिल है, जो अनपेक्षित उपयोगकर्ताओं को व्यक्तिगत प्रक्रियाओं को प्रोफाइल करने की अनुमति देता है।

चतुर्थ। Google perftools

यह प्रोफाइलर Google perftools सुइट का हिस्सा है। मुझे इसकी समीक्षा हाब पर नहीं मिली, इसलिए मैं इसका संक्षेप में वर्णन करूंगा।
किट में C / C ++ अनुप्रयोगों को तेज करने और विश्लेषण करने के उद्देश्य से पुस्तकालयों की एक श्रृंखला शामिल है। केंद्रीय भाग tcmalloc एलोकेटर है , जो मेमोरी के आवंटन में तेजी लाने के अलावा, क्लासिक समस्याओं - मेमोरी लीक और हीप प्रोफाइल का विश्लेषण करने के लिए उपकरण ले जाता है।

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

ऐसा करने के बारे में कुछ विवरण यहां दिए गए हैं।

1. डिफ़ॉल्ट रूप से, ITIMER_PROF टाइमर को टाइमर सिग्नल द्वारा चुना जाता है, जो केवल CPU प्रोग्राम का उपयोग करते समय टिक करता है। आखिरकार, एक नियम के रूप में, हम बहुत रुचि नहीं रखते हैं जहां कार्यक्रम सॉकेट पर कीबोर्ड इनपुट या डेटा इनपुट की प्रतीक्षा कर रहा था। और यदि आप अभी भी रुचि रखते हैं, तो env CPUPROFILE_REALTIME=1 उपयोग करें

2. कॉल स्टैक या तो लिबुनविंड या मैन्युअल रूप से उपयोग किया जाता है (जिसके लिए --fno-omit-framepointer की आवश्यकता होती है, यह हमेशा x86 पर काम करता है)।
3. फ़ंक्शन नाम बाद में addr2line (1) का उपयोग करके पहचाने जाते हैं
4. अन्य Google perftools टूल की तरह, प्रोफाइलर को स्पष्ट रूप से जोड़ा जा सकता है, या इसे LD_PRELADAD टूल के साथ प्री लोड किया जा सकता है।

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

यह प्रोफाइलर पहले से चल रहे कार्यक्रमों के साथ काम करने के लिए भी डिज़ाइन नहीं किया गया है।
हाल के संस्करण कांटा (2) के साथ काम नहीं करते हैं, कभी-कभी इसे डेमों में उपयोग करना मुश्किल होता है

Crxprof

जैसा कि वादा किया गया है, अब एक और प्रोफाइलर के बारे में जो विशेष रूप से ऊपर बताई गई समस्या को हल करने के लिए लिखा गया है - पहले से चल रही प्रक्रियाओं की आसान रूपरेखा।

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

कुछ काम का विवरण

मूल रूप से, crxprof, perftools की तरह ही काम करता है, लेकिन ptrace (2) के माध्यम से बाहरी रूपरेखा का उपयोग करता है। पेरफुटॉल्स की तरह, यह स्टैक को स्पिन करने के लिए लिबुनविंड का उपयोग करता है, और फ़ंक्शन नामों को परिवर्तित करने के कठिन परिश्रम के बजाय, addr2line (1) के बजाय libbfd का उपयोग किया जाता है।

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

समानांतर में, कॉल ग्राफ बनाया गया है, यह मानते हुए कि एक निश्चित केंद्रीय कार्य है - प्रवेश बिंदु। यह आमतौर पर lib लाइब्रेरी से __libc_start_main है।

स्रोत कोड github पर उपलब्ध है। क्योंकि मेरे और मेरे सहयोगियों के लिए उपयोगिता बनाई गई थी, मैं पूरी तरह से मानता हूं कि यह आपके उपयोग-मामले के अनुरूप नहीं हो सकता है। वैसे भी, पूछो।

आइए crxprof का निर्माण करें और इसके उपयोग के एक उदाहरण को देखें।

सभा

आपको क्या चाहिए: लिनक्स (2.6+), ऑटोकॉन्फ़ + ऑटोमैटिक, बिनुटिल्स-देव (लिब्फ़्ड शामिल), लिबुनविंड-देव (मैंने इसे लिबुनविंड8-देव कहा है)।
बनाने के लिए, हम प्रदर्शन करते हैं:

 autoreconf -fiv ./configure make sudo make install

यदि लिबुनविंड गैर-मानक स्थान में स्थापित है, तो उपयोग करें:

 ./configure --with-libunwind=/path/to/libunwind

रूपरेखा

ऐसा करने के लिए, बस चलाएं

 crxprof pid

और वह सब है! अब कंसोल में प्रोफ़ाइल को आउटपुट करने के लिए ENTER का उपयोग करें, और ^ C को पूरा करने के लिए। Crxprof भी बाहर निकलने पर प्रोफ़ाइल का उत्पादन करेगा।

crxprof: ptrace (PTRACE_ATTACH) विफल: ऑपरेशन की अनुमति नहीं है

यदि आप यह त्रुटि देखते हैं, तो आपके सिस्टम पर ptrace "सीमित" है। (उबंटू?)
अधिक विवरण यहां पढ़ा जा सकता है।
संक्षेप में, या तो sudo से शुरू करते हैं, या (बेहतर) कंसोल में चलते हैं:

 $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

सभी यूनिक्स उपयोगिताओं की तरह, crxprof जब --help स्विच के साथ प्रयोग किया जाता है। man crxprof देखें

crxprof-help

 उपयोग: crxprof [विकल्प] पीआईडी
 विकल्प हैं:
  -t | - थ्रेशोल्ड एन: उन नोड्स की कल्पना करें जो कम से कम एन% समय लेता है (डिफ़ॉल्ट: 5.0)
  -d | --dump फ़ाइल: दिए गए FILE को कॉलगर्ल डंप सहेजें
  -f | --freq FREQ: FREQ हर्ट्ज के लिए प्रोफाइल आवृत्ति सेट करें (डिफ़ॉल्ट: 100)
  -m | --मैक्स-डेप्थ एन: विज़ुअलाइज़ करते समय अधिकांश एन स्तरों पर दिखाएं (डिफ़ॉल्ट: कोई सीमा नहीं)
  -r | --realtime: CPU की जगह रीयलटाइम प्रोफाइल का उपयोग करें
  -एच | --हेल्प: यह मदद दिखाएं
 
  -फुट-स्टैक: विजुअलाइज करते समय फुल स्टैक प्रिंट करें
  -प्रिंट-सिंबल: सिर्फ फन और ऐड प्रिंट (और छोड़ें)

वास्तविक उदाहरण

एक वास्तविक, लेकिन जटिल उदाहरण नहीं देने के लिए, मैं इस कोड का उपयोग सी। संकलन में करता हूं, इसे चलाता हूं और फ़ंक्शन कॉल ग्राफ (4054 - प्रोग्राम के पिड को प्रोफाईल किया जा रहा है) को बचाने के लिए crxprof से पूछता हूं:

 $ crxprof -d /tmp/test.calls 4054 Reading symbols (list of function) reading symbols from /home/dkrot/work/crxprof/test/a.out (exe) reading symbols from /lib/x86_64-linux-gnu/libc-2.15.so (dynlib) reading symbols from /lib/x86_64-linux-gnu/ld-2.15.so (dynlib) Attaching to process: 6704 Starting profile (interval 10ms) Press ENTER to show profile, ^C to quit 1013 snapshot interrputs got (0 dropped) main (100% | 0% self) \_ heavy_fn (75% | 49% self) \_ fn (25% | 25% self) \_ fn (24% | 24% self) Profile saved to /tmp/test.calls (Callgrind format) ^C--- Exit since ^C pressed

कंसोल पर प्रदर्शित आंकड़े बताते हैं कि:

main () कॉल Heavy_fn () और (यह सबसे कठिन तरीका है)
Heavy_fn () कॉल fn ()
main () भी fn () को सीधे कॉल करता है
Heavy_fn () में CPU का आधा समय लगता है
fn () शेष सीपीयू समय लेता है
मुख्य () अपने आप कुछ भी उपभोग नहीं करता है

विज़ुअलाइज़ेशन योजना के अनुसार किया जाता है "सबसे बड़ा उपशीर्षक - पहले।" इस प्रकार, यहां तक कि बड़े वास्तविक कार्यक्रमों के लिए, आप कंसोल में सरल दृश्य का उपयोग कर सकते हैं, जो सर्वर पर सुविधाजनक होना चाहिए।

जटिल कॉल ग्राफ़ की कल्पना करने के लिए, Kacheacheind का उपयोग करना सुविधाजनक है:

 $ kcachegrind /tmp/test.calls

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

पहले से चल रहे कार्यक्रमों की रूपरेखा तैयार करना