🐙 🧗🏿 🉑 सुपरलाइट वेग प्रोफाइलिंग: सिद्धांत और व्यवहार। भाग 1 📢 👩🏽‍🤝‍👨🏻 💇🏽

नमस्ते! शीर्षक से, आप पहले से ही समझ गए थे कि मैं किस बारे में बात करने जा रहा हूं। बहुत कट्टर होगा:
हम जावा, सी, सी ++, असेंबलर, लिनक्स के एक बिट, ऑपरेटिंग सिस्टम के कर्नेल के एक बिट पर चर्चा करेंगे। हम एक व्यावहारिक मामले का भी विश्लेषण करेंगे, इसलिए यह लेख तीन बड़े भागों (काफी मात्रा में) में होगा।

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

सामग्री

समय और समझ का साधन - प्रोफाइलर

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

मान लीजिए कि हम एक ऐसा अनुप्रयोग विकसित कर रहे हैं जो अपने आप में महत्वपूर्ण है कि गति के लिए पर्याप्त है, और कुछ कोड टुकड़ों के लिए यह आम तौर पर महत्वपूर्ण है। ये टुकड़े निष्पादित होते हैं, कहते हैं, सैकड़ों माइक्रोसेकंड - जल्दी से पर्याप्त, लेकिन वे [ कोड के अनुभाग ] सीधे हमारे आवेदन की सफलता और अर्जित धन या खोए हुए राशि को प्रभावित करते हैं। उदाहरण के लिए
विनिमय लेनदेन को समाप्त करने के आदेश भेजते समय, 100 माइक्रोसेकंड की देरी से प्रत्येक लेनदेन पर 1 मिलियन रूबल या उससे अधिक की लागत हो सकती है, जो एक, दो नहीं, या यहां तक कि एक सौ से पूरा नहीं होता है।

और कार्य मेरे लिए निर्धारित किया गया था: एक तरफ, आपको एक ही समय में सभी आदेश भेजने की आवश्यकता है, और दूसरी तरफ, उन्हें भेजें ताकि पहले और आखिरी के बीच का विचरण न्यूनतम हो। यही है, एक फ़ंक्शन को प्रोफाइल करना आवश्यक था जो एक्सचेंज को ऑर्डर भेजता है। एक छोटे से अति सूक्ष्म अंतर को छोड़कर एक विशिष्ट कार्य: इस फ़ंक्शन की विशेषता निष्पादन समय 100 μs से काफी कम है ।

आइए इस बारे में सोचें कि हम ये 100 μ कैसे प्रोफाइल करते हैं ताकि यह समझ सकें कि अंदर क्या हो रहा है।
इस उपकरण को चुनते समय क्या विचार करें?

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

हम इन सभी बारीकियों को कैसे ध्यान में रखते हैं और ब्याज की विधि को सही ढंग से प्रोफाइल करते हैं?

वैचारिक रूप से, सभी प्रोफाइलरों को प्रोफाइलर्स इंस्ट्रूमेंटिंग या सैंपलिंग के दो समूहों में विभाजित किया जा सकता है। आइए प्रत्येक समूह पर अलग से विचार करें।

टूलींग प्रोफाइल ओवरहेड में काफी योगदान करते हैं क्योंकि वे हमारे बायटेकोड को संशोधित करते हैं और इसमें एक समय रिकॉर्ड दर्ज करते हैं। इसलिए ऐसे प्रोफाइलरों की मुख्य खामी: वे निष्पादन योग्य कोड को महत्वपूर्ण रूप से प्रभावित कर सकते हैं। नतीजतन, यह कहना मुश्किल होगा कि परिणामी प्रोफ़ाइल उत्पादन सर्वरों पर व्यवहार से कितना मेल खाती है: कुछ अनुकूलन अलग तरीके से काम कर सकते हैं, कुछ होते हैं, और कुछ नहीं। शायद, अन्य समय के पैमाने पर - सेकंड, मिनट, घंटे - हम प्रतिनिधि डेटा प्राप्त करेंगे। लेकिन 100 μs के पैमाने पर, ट्रिगर या विफल ऑप्टिमाइज़ेशन से प्रोफ़ाइल पूरी तरह से अप्रस्तुत हो सकती है। तो चलो प्रोफाइलरों के एक अन्य समूह पर करीब से नज़र डालें।

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

नमूना प्रोफाइलर कैसे काम करते हैं?

यह समझने के लिए कि एक नमूना प्रोफाइलर कैसे काम करता है, निम्न उदाहरण पर विचार करें - SendToMoex विधि कई अन्य विधियों को कॉल करती है। हम देखते हैं:

void sendToMoex() { a.qqq(); b.doo(); c.ccc() } void doo() { da(); db(); }

यदि हम कार्यक्रम के इस खंड के निष्पादन के समय कॉल स्टैक की स्थिति की निगरानी करते हैं और समय-समय पर इसे रिकॉर्ड करते हैं, तो हम इस फॉर्म के बारे में जानकारी प्राप्त करेंगे:

यह कॉल स्टैक का एक सेट है। यह मानते हुए कि नमूने समान रूप से वितरित किए जाते हैं, समरूप ढेर की संख्या उस विधि के सापेक्ष निष्पादन समय को इंगित करती है जो स्टैक के शीर्ष पर है।

इस उदाहरण में, दा विधि को C.ccc विधि जितना ही किया गया था, और यह Db विधि से 2 गुना अधिक है। हालांकि, यह धारणा कि नमूनों का वितरण पूरी तरह से सही नहीं है, और फिर निष्पादन समय का अनुमान गलत होगा।

हमें कितनी बार नमूना लेने की आवश्यकता है?

मान लीजिए कि हम 100 माइक्रोसेकंड में 1000 नमूने लेना चाहते हैं यह समझने के लिए कि अंदर क्या खेला गया था। अगला, हम एक सरल अनुपात के साथ गणना करते हैं कि यदि हमें 100 μ में 1000 नमूने करने की आवश्यकता है, तो यह 1 सेकंड या 10,000,000 नमूनों / s में 10 मिलियन नमूने हैं।

यदि हम इस गति से नमूना लेते हैं, तो कोड के एक निष्पादन में हम 1000 नमूने एकत्र करेंगे, जो कि जल्दी या धीरे-धीरे काम करेंगे, समझेंगे। उसके बाद, हम प्रदर्शन का विश्लेषण करेंगे और कोड को समायोजित करेंगे।

हालांकि, प्रति सेकंड 10 मिलियन नमूनों की आवृत्ति बहुत कुछ है। और अगर हम शुरू से ही प्रोफाइलिंग की ऐसी रफ्तार हासिल करने में नाकाम रहे तो? मान लीजिए कि हमने 10 μ के लिए केवल 10 नमूने एकत्र किए, 1000 नहीं। इस मामले में, हमें प्रोफाइल कोड के अगले निष्पादन के लिए प्रतीक्षा करने की आवश्यकता है, जो 1 सेकंड के बाद होगा (आखिरकार, प्रोफाइल कोड प्रति सेकंड एक बार निष्पादित होता है)। इसलिए हम 10 और नमूने एकत्र करेंगे। चूंकि वे समान रूप से हमारे साथ वितरित किए जाते हैं, उन्हें एक सामान्य सेट में जोड़ा जा सकता है। यह प्रतीक्षा करने के लिए पर्याप्त है जब तक कि प्रोफाइल कोड 1000/10 = 100 बार निष्पादित नहीं हो जाता है, और हम आवश्यक 1000 नमूने (प्रत्येक 100 बार 10 नमूने) एकत्र करेंगे।

एक प्रोफाइलर चुनें

इस सैद्धांतिक ज्ञान के साथ, चलो अभ्यास करने के लिए आगे बढ़ते हैं।

Async-profiler लें । एक महान उपकरण (AsyncGetCallTrace वर्चुअल मशीन कॉल का उपयोग करता है) जो जावा वर्चुअल मशीन के बाइट कोड के निर्देश तक कॉल स्टैक को एकत्र करता है। देशी async- प्रोफाइलर नमूना दर प्रति सेकंड 1000 नमूने है ।

हम एक सरल अनुपात हल करेंगे: 10,000,000 नमूने / सेकंड - 1 सेकंड, 1000 नमूने / सेकंड - एक्स सेकंड।
हमें यह मिलता है कि async-profiler के मानक नमूने की आवृत्ति पर, प्रोफाइलिंग में लगभग 3 घंटे लगेंगे। यह एक लंबा समय है। आदर्श रूप से, मैं प्रोफाइल को जल्दी से जल्दी इकट्ठा करना चाहता हूं, सुपरमूलिनल गति से ही सही।

आइए Async-profiler को ओवरक्लॉक करने का प्रयास करें। ऐसा करने के लिए, रीडमी में, हमें -i झंडा लगता है, जो नमूना अंतराल सेट करता है। आइए, -i1 ध्वज (1 नैनोसेकंड), या -i0 को सामान्य रूप से सेट करने का प्रयास करें, ताकि प्रोफाइलर बिना रुके नमूना ले सके। मुझे प्रति सेकंड लगभग 2.5 हजार नमूनों की आवृत्ति मिली। इस मामले में, प्रोफाइलिंग की कुल अवधि लगभग 1 घंटे होगी। बेशक, 3 घंटे नहीं, लेकिन बहुत तेज़ भी नहीं। ऐसा लगता है कि आवश्यक रूपरेखा गति प्राप्त करने के लिए, आपको नए स्तर तक पहुंचने के लिए गुणात्मक रूप से कुछ अलग करने की आवश्यकता है।

उच्चतर आवृत्तियों को प्राप्त करने के लिए, आपको AsyncGetCallTrace कॉल को छोड़ना होगा और प्रत्येक पूर्ण वितरण लिनक्स में पाए जाने वाले पूर्ण-कालिक लिनक्स प्रोफाइलर का उपयोग करना होगा। हालाँकि, Java के बारे में perf कुछ भी नहीं जानता है, और हमारे पास अभी तक Java के साथ काम करने के लिए perf को प्रशिक्षित करना है। इस बीच, आइए इस डरावने तरीके से परफेक्ट चलने की कोशिश करें:

 $ perf record –F 10000 -p PID -g -- sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: .. 0.215 MB perf.data (4032 samples) ]

संकेतन के बारे में अधिक

perf record का मतलब है कि हम एक प्रोफाइल रिकॉर्ड करना चाहते हैं।
-F झंडा और तर्क 10,000 नमूना दर है।
-p ध्वज इंगित करता है कि हम अपनी जावा प्रक्रिया के केवल विशिष्ट PID को प्रोफाइल करना चाहते हैं।
-g ध्वज कॉल स्टैक एकत्रित करने के लिए ज़िम्मेदार है।
अंत में, नींद 1 के साथ , हम प्रोफ़ाइल प्रविष्टि को 1 सेकंड तक सीमित करते हैं।

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

जावा एप्लिकेशन प्रोफ़ाइल बनाने के लिए पूर्ण जानें।

हम परफेक्ट रिकॉर्ड को निष्पादित करते हैं ... कमांड, 1 सेकंड प्रतीक्षा करें और यह देखने के लिए परफेक्ट स्क्रिप्ट चलाएं कि क्या प्रोफाइल किया गया है? और हम कुछ स्पष्ट नहीं देखेंगे:

 $ perf script java 8079 2008793.746571: 3745505 cycles:uppp: 7fa1e88b53f8 [unknown] (/tmp/perf-11038.map) java 8079 2008793.747565: 3728336 cycles:uppp: 7fa1e88b5372 [unknown] (/tmp/perf-11038.map) java 8079 2008793.748613: 3731147 cycles:uppp: 7fa1e88b53ef [unknown] (/tmp/perf-11038.map)

यह पते से प्रतीत होता है, लेकिन जावा विधियों के नाम नहीं हैं। तो, आपको इन पतों को विधियों के नाम के साथ मिलान करने के लिए पूर्ण सिखाने की आवश्यकता है।

C और C ++ की दुनिया में, तथाकथित डिबगिंग जानकारी का उपयोग पते और फ़ंक्शन के नामों से मेल खाने के लिए किया जाता है। एक पत्राचार निष्पादन योग्य फ़ाइल के एक विशेष खंड में संग्रहीत किया जाता है: एक विधि ऐसे पतों पर निहित होती है, दूसरी विधि अन्य पतों पर होती है। Perf इस जानकारी को खींचता है और मैपिंग करता है।

जाहिर है, वर्चुअल मशीन JIT कंपाइलर इस प्रारूप में डिबगिंग जानकारी उत्पन्न नहीं करता है। हमारे पास अभी भी एक और तरीका है - एक विशेष perf-map फ़ाइल में पतों और तरीकों के नामों के पत्राचार पर डेटा लिखने के लिए, जो कि पठन डीबग जानकारी के अतिरिक्त के रूप में इलाज करेगा। यह perf-map फ़ाइल tmp फ़ोल्डर में होनी चाहिए और इसमें निम्न डेटा संरचना होनी चाहिए:

विधि कोड प्रारंभ पता	कोड की लंबाई	विधि का नाम
7f99a911d600	120	java.util.AbstractCollection। <init>
7f99a911d9c0	180	java.util.AbstractList। <init>
7f99a911de80	5c0	java.util.Arrays.copyOf
7f99a911ed40	140	java.util.ArrayList $ Itr.hasNext
7f99a911f200	3e0	java.util.ArrayList $ Itr.next

पहला कॉलम विधि कोड की शुरुआत का पता है, दूसरा इसकी लंबाई है, तीसरा कॉलम विधि का नाम है।

इसलिए, हमें एक समान फ़ाइल बनाने की आवश्यकता है। जाहिर है, हम इसे मैन्युअल रूप से करने में सक्षम नहीं होंगे (हमें कैसे पता चलेगा कि जेआईटी कंपाइलर कोड को किस पते पर रखेगा), इसलिए हम perf-map-agent प्रोजेक्ट से create-java-perf-map.sh स्क्रिप्ट का उपयोग करेंगे, इसे हमारी जावा प्रक्रिया का PID पास करेंगे। । फ़ाइल तैयार है, इसकी सामग्री की जांच करें, फिर से परिपूर्ण स्क्रिप्ट चलाएं।

 $ perf script java 8080 1895245.867498: cycles:uppp: 7fb2dd10f527 Loop3.doRecursiveCall (/tmp/perf-8079.map) java 8080 1895245.868176: 2127960 cycles:uppp: 7fb2dd10f57f Loop3.doRecursiveCall (/tmp/perf-8079.map) java 8080 1895245.868737: 1959990 cycles:uppp: 7fb2dd10f627 Loop3.doRecursiveCall (/tmp/perf-8079.map)

देखा! हम जावा विधियों के नाम देखते हैं! बस क्या हुआ: हमने परफ़ेक्ट प्रोफाइलर को सिखाया, जो जावा के बारे में कुछ नहीं जानता, एक नियमित जावा एप्लीकेशन को प्रोफाइल करने और इस एप्लिकेशन के हॉट जावा तरीके देखने के लिए!

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

कॉल स्टैक कैसे प्राप्त करें?

अब आपको कॉल स्टैक प्राप्त करने के लिए पूर्ण या वर्चुअल मशीन के साथ कुछ और करने की आवश्यकता है। यह समझने के लिए कि क्या किया जाना चाहिए, आइए एक कदम वापस लें और देखें कि स्टैक आमतौर पर कैसे काम करता है। कल्पना कीजिए कि हमारे पास तीन कार्य f1, f2, f3 हैं। इसके अलावा, f1 कॉल f2, और f2 कॉल f3।

 void f1() { f2(); } void f2() { f3(); } void f3() { ... }

जिस समय फ़ंक्शन f3 निष्पादित होता है, तो देखते हैं कि स्टैक किस स्थिति में है। हम rsp रजिस्टर देखते हैं, जो स्टैक के शीर्ष पर स्थित है। हम यह भी जानते हैं कि स्टैक में पिछले स्टैक फ्रेम का पता होता है। और मुझे कॉल-स्टैक कैसे मिल सकता है?

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

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

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

हम एक नए झंडे के साथ वर्चुअल मशीन शुरू करते हैं। create-java-perf-map , उसके बाद perf record और perf script चलाएँ। अब हम कॉल स्टैक के साथ एक सटीक प्रोफ़ाइल बना सकते हैं:

 $ perf script java 18657 1901247.601878: 979583 cycles:uppp: 7fbfd1101edc Loop3.doRecursiveCall (...) 7fbfd1101edc Loop3.doRecursiveCall (...) 7fbfd1101edc Loop3.doRecursiveCall (...) 7fbfd1101edc Loop3.doRecursiveCall (...) 7f285d007b10 Interpreter (...) 7f285d0004e7 call_stub (...) 67d0db [unknown] (... libjvm.so) ... 708c start_thread (... libpthread-2.26.so)

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

पूर्ण नमूना दर में वृद्धि

आइए प्रति सेकंड 10 मिलियन नमूनों तक इत्र को ओवरक्लॉक करने का प्रयास करें। अब हमारे पास काफी कम आवृत्ति है।

हमारे द्वारा अभी-अभी किए गए सभी कार्यों को स्वचालित करने के लिए, आप perf-java-record-stack script का उपयोग perf-map-Agent प्रोजेक्ट से कर सकते हैं। उसके पास एक अद्भुत कलम है - पर्यावरण चर perf_record-freq , जिसके साथ आप नमूना आवृत्ति सेट कर सकते हैं। पहले, चलो प्रति सेकंड 100 हजार नमूने सेट करें और चलाने का प्रयास करें। कंसोल में एक भयानक संदेश दिखाई देता है कि हमने अधिकतम स्वीकृत नमूना आवृत्ति को पार कर लिया है:

 $ PERF_RECORD_FREQ=100000 ./bin/perf-java-record-stack PID ... Maximum frequency rate (30000) reached. Please use -F freq option with lower value or consider tweaking /proc/sys/kernel/perf_event_max_sample_rate. ...

मेरे मामले में, सीमा प्रति सेकंड 30 हजार नमूने थे। Perf तुरंत कहता है कि किस कर्नेल तर्क को ठीक करने की आवश्यकता है, जिसे हम या तो गूंज सुडो टी का उपयोग वांछित फ़ाइल में, या सीधे sysctl माध्यम से करेंगे। इसलिए:

 $ echo '1000000' | sudo tee /proc/sys/kernel/perf_event_max_sample_rate

या तो:

 $ sudo sysctl kernel.perf_event_max_sample_rate=1000000

अब हम कर्नेल को बता रहे हैं कि आवृत्ति की ऊपरी सीमा अब प्रति सेकंड 1 मिलियन नमूने है। हम फिर से प्रोफाइलर शुरू करते हैं और प्रति सेकंड 200 हजार नमूनों की आवृत्ति का संकेत देते हैं। प्रोफाइलर 15 सेकंड के लिए काम करेगा और हमें 1 मिलियन नमूने देगा। सब कुछ ठीक लगने लगा है। कम से कम कोई दुर्जेय त्रुटि संदेश नहीं। लेकिन वास्तव में हमें क्या आवृत्ति मिली? यह पता चला है कि प्रति सेकंड केवल 70 हजार नमूने हैं। क्या गलत हुआ?

आइए देखते हैं dmesg का आउटपुट:

 [84430.412898] perf: interrupt took too long (1783 > 200), lowering kernel.perf_event_max_sample_rate to 89700 ... [84431.618452] perf: interrupt took too long (2229 > 2228), lowering kernel.perf_event_max_sample_rate to 71700

यह लिनक्स कर्नेल का आउटपुट है। यह महसूस किया कि हम बहुत बार नमूना लेते हैं, और इसमें बहुत अधिक समय लगता है, इसलिए कर्नेल आवृत्ति को कम करता है। यह पता चला है कि हमें कर्नेल में एक और हैंडल को kernel.perf_cpu_time_max_percent करने की आवश्यकता है - इसे कर्नेल कहा जाता है। kernel.perf_cpu_time_max_percent और कर्नेल kernel.perf_cpu_time_max_percent से इंटरप्ट पर खर्च होने वाले समय को नियंत्रित करता है।

हम प्रति सेकंड 200 हजार नमूनों की एक नमूना आवृत्ति का आदेश देंगे। और 15 सेकंड के बाद हमें 3 मिलियन नमूने मिलते हैं - प्रति सेकंड 200 हजार नमूने।

 $ PERF_RECORD_FREQ=200000 ./bin/perf-java-record-stack PID Recording events for 15 seconds ... ... [ perf record: Captured ... (2.961.252 samples) ]

अब प्रोफाइल देखते हैं। पूर्ण perf script चलाएँ:

 $ perf script ... java ... native_write_msr (/.../vmlinux) java ... Loop2.main (/tmp/perf-29621.map) java ... native_write_msr (/.../vmlinux) ...

हम अजीब कार्यों और vmlinux निष्पादन योग्य मॉड्यूल - लिनक्स कर्नेल देखते हैं। यह निश्चित रूप से हमारा कोड नहीं है। क्या हुआ था? आवृत्ति इतनी अधिक हो गई कि कर्नेल कोड नमूनों में गिरना शुरू हो गया। यही है, जितना अधिक हम आवृत्ति बढ़ाते हैं, उतने ही नमूने होंगे जो हमारे कोड से संबंधित नहीं हैं, लेकिन लिनक्स कर्नेल से संबंधित हैं।

मृत अंत।

हम स्पष्ट रूप से हार्डवेयर पीएमयू / पीईबीएस घटनाओं का उपयोग करते हैं

तब मैंने PMU / PEBS हार्डवेयर तकनीक - प्रदर्शन निगरानी इकाई, सटीक घटना आधारित नमूनाकरण का उपयोग करने का प्रयास करने का निर्णय लिया। यह आपको सूचनाएँ प्राप्त करने की अनुमति देता है कि एक घटना कई बार दी गई है। इसे "अवधि" कहा जाता है। उदाहरण के लिए, हम हर 20 वें अनुदेश के प्रोसेसर द्वारा निष्पादन के बारे में सूचनाएं प्राप्त कर सकते हैं। आइए एक उदाहरण देखें। अब xor निर्देश को निष्पादित किया जाए, और PMU काउंटर को मान 18 प्राप्त हो; फिर निर्देश आता है - काउंटर 19 है; और अगला निर्देश, % r14,% r13 जोड़ें , PMU "हॉट" के रूप में दिखाई देगा।

फिर एक नया चक्र शुरू होता है: inc को निष्पादित किया जाता है - PMU 1 पर रीसेट होता है। चक्र के कुछ और पुनरावृत्तियों से गुजरता है। अंत में, हम mov इंस्ट्रक्शन पर रुक जाते हैं, पीएमयू 19 को स्नैप करता है। अगला ऐड स्टेटमेंट, और फिर हम इसे हॉट मार्क करते हैं। लिस्टिंग देखें:

 mov aaa, bbbb xor %rdx, %rdx L_START: mov $0x0(%rbx, %rdx),%r14 add %r14, %r13 ; (PMU       "") cmp %rdx,100000000 jne L_START

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

PMU / PEBS तकनीक को कम से कम 2009 के बाद से इसके आधुनिक रूप में समर्थित किया गया है, अर्थात यह लगभग किसी भी कंप्यूटर पर उपलब्ध है। इसे स्पष्ट रूप से लागू करने के लिए, हम perf-java-record-stack script को संशोधित करते हैं। -F ध्वज को -e बदलें, जो स्पष्ट रूप से PMU / PEBS के उपयोग को निर्दिष्ट करता है।

 ... sudo perf record -F $PERF_RECORD_FREQ ... ...

स्क्रिप्ट को बदलना:

 ... sudo perf record -e cycles –c 10007 ... ...

आपको पहले से ही पता है कि एक अवधि में क्या गुण होने चाहिए - हमें एक प्रमुख संख्या की आवश्यकता है। हमारे मामले के लिए, यह 10007 की अवधि होगी।

उन्होंने संशोधित perf-java-record-stack-script लॉन्च की और 15 सेकंड में 4.5 मिलियन नमूने प्राप्त किए - प्रति सेकंड लगभग 300 हजार नमूने, प्रत्येक 3 माइक्रोसेकंड का एक नमूना। यही है, हमारे प्रोफाइल कोड के एक निष्पादन के लिए, 100 μs के लिए हम 33 नमूने एकत्र करेंगे। इस आवृत्ति पर, कुल प्रोफ़ाइल संग्रह का समय केवल 30 सेकंड है। एक कप कॉफी भी न पिएं! वास्तव में, सब कुछ थोड़ा और अधिक जटिल है। अगर हमारा कोड प्रति सेकंड एक बार नहीं, बल्कि हर 5 सेकंड में एक बार निष्पादित होना शुरू हो जाए तो क्या होगा? फिर प्रोफाइलिंग की अवधि 2.5 मिनट तक बढ़ेगी, जो काफी सभ्य परिणाम भी है।

इसलिए, 30 सेकंड में आप एक ऐसी प्रोफ़ाइल प्राप्त कर सकते हैं जो हमारे सभी अनुसंधान आवश्यकताओं को पूरी तरह से कवर करती है। जीतना?

लेकिन कुछ गंदी चाल की भावना ने मुझे नहीं छोड़ा। आइए उस स्थिति पर लौटते हैं जिसमें हमारा कोड हर 5 सेकंड में निष्पादित होता है। फिर प्रोफाइलिंग में 150 सेकंड का समय लगेगा, इस दौरान हम लगभग 45 मिलियन नमूने एकत्र करेंगे। इनमें से हमें केवल 1000 की जरूरत है, यानी 0.002% डेटा एकत्र किया गया है। बाकी सब कुछ कचरा है, जो अन्य उपकरणों के काम को धीमा कर देता है और ओवरहेड जोड़ता है। हां, समस्या हल हो गई है, लेकिन यह माथे, गंदे, कुंद बल में हल हो गई है।

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

संक्षिप्त सारांश:

Perf का उपयोग करके Java एप्लिकेशन की एक प्रोफ़ाइल बनाने के लिए, आपको perf-map-agent प्रोजेक्ट से स्क्रिप्ट का उपयोग करके प्रतीकों के बारे में जानकारी के साथ एक फ़ाइल बनाने की आवश्यकता है
न केवल कोड के गर्म वर्गों के बारे में जानकारी इकट्ठा करने के लिए, बल्कि ढेर भी, आपको -XX के साथ एक वर्चुअल मशीन चलाने की आवश्यकता है: + PreserveFramePointer झंडा
यदि आप सैंपलिंग फ़्रीक्वेंसी को बढ़ाना चाहते हैं, तो आपको sysctl'i और kernel.perf_cpu_time_max_percent और kernel.perf_event_max_sample_rate पर ध्यान देना चाहिए।
यदि कर्नेल के नमूने जो अनुप्रयोग से संबंधित नहीं हैं, तो प्रोफ़ाइल में जाना शुरू हो गया है, तो आपको पीएमयू / पीईबीएस अवधि को स्पष्ट रूप से निर्दिष्ट करने के बारे में सोचना चाहिए।

यह लेख (और उसके बाद के हिस्से) पाठ के रूप में अनुकूलित रिपोर्ट का एक प्रतिलेख है। यदि आप न केवल पढ़ना चाहते हैं, बल्कि प्रोफाइलिंग, प्रस्तुति का एक संदर्भ भी सुन सकते हैं।

सुपरलाइट वेग प्रोफाइलिंग: सिद्धांत और व्यवहार। भाग 1