सात निर्देशों से बंद 63 कोरे

मुझे लगता है कि शक्तिशाली मशीनों के बारे में लिखने की आदत है, जहां कई ताले गलत ताले के कारण बेकार हैं। तो ... हाँ। उसके बारे में फिर से।

यह कहानी विशेष रूप से प्रभावशाली है। वास्तव में, कितनी बार आपके पास सात सेकंड के चक्र में कुछ सेकंड के लिए एक थ्रेड स्पिन होता है, एक लॉक पकड़े जो 63 प्रोसेसर के काम को रोक देता है? यह सिर्फ आश्चर्यजनक है, कुछ भयानक अर्थों में।

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

मित्र की शिकायत काफी सरल थी: उसने निन्जा का उपयोग कर निर्माण एकत्र किया। आमतौर पर, निंजा बढ़ते भार का एक बड़ा काम करता है, डाउनटाइम से बचने के लिए लगातार n + 2 प्रक्रियाओं का समर्थन करता है। लेकिन यहां, विधानसभा के पहले 17 सेकंड में सीपीयू का उपयोग इस तरह देखा गया:



यदि आप एक नज़दीकी नज़र (एक मज़ाक) लेते हैं, तो आप एक पतली रेखा देख सकते हैं जहाँ कुल सीपीयू लोड कुछ ही सेकंड में 100% से 0% तक हो जाता है। सिर्फ आधे सेकंड में, लोड 64 से दो या तीन थ्रेड तक कम हो जाता है। यहाँ इन फॉल्स में से एक का एक बड़ा टुकड़ा है - सेकंड क्षैतिज अक्ष के साथ चिह्नित हैं:



पहले सोचा था कि निंजा जल्दी से प्रक्रिया नहीं बना सकते हैं। मैंने इसे कई बार देखा है, आमतौर पर एंटीवायरस सॉफ़्टवेयर के हस्तक्षेप के कारण। लेकिन जब मैंने अंत समय तक चार्ट को छांटा, तो मैंने पाया कि ऐसी दुर्घटनाओं के दौरान कोई प्रक्रिया पूरी नहीं हुई, इसलिए निंजा को दोष नहीं देना है।

CPU उपयोग (सटीक) तालिका डाउनटाइम के कारण की पहचान करने के लिए आदर्श है। सभी संदर्भ स्विच के लॉग वहां संग्रहीत किए जाते हैं, जिसमें स्ट्रीम के प्रत्येक प्रारंभ के सटीक रिकॉर्ड शामिल हैं, जिसमें जगह और टाइमआउट शामिल हैं।

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

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



मैंने बारह मिलीसेकंड में ज़ूम किया और 500 संदर्भ स्विच पाए, यहां एक सावधानीपूर्वक विश्लेषण की आवश्यकता है।

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

इसलिए, मैंने कार्यक्रम में एक अलग कॉलम लेआउट की कोशिश की:

• स्विच-इन टाइम (जब संदर्भ स्विचिंग हुआ)
  
• पढ़ने की प्रक्रिया (जिसने प्रतीक्षा के बाद ताला जारी किया)
  
• नई प्रक्रिया (जिसने काम करना शुरू किया)
  
• अंतिम समय (नई प्रक्रिया कब तक प्रतीक्षा कर रही है)

यह संदर्भ स्विच की एक समय-क्रमबद्ध सूची देता है कि कौन किसकी तैयारी में है और कब और कितनी देर तक प्रक्रियाएं तैयार की गई हैं।

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



यह रेखा कहती है कि सिस्टम (4) तैयार सीएल। Exe (3032) , जिसने 3.368 सेकंड इंतजार किया। अगली पंक्ति कहती है कि 0.1 मिसे से कम समय में, cl। Exe (3032) तैयार किए गए cl.exe (16232) , जिसने 667 सेकंड इंतजार किया। और इसी तरह।

लाइन # 7 के रूप में कई संदर्भ स्विच, प्रतीक्षा श्रृंखला में शामिल नहीं हैं, लेकिन बस सिस्टम में अन्य काम को दर्शाते हैं, लेकिन सामान्य रूप से श्रृंखला कई तत्वों के दसियों तक फैली हुई है।

इसका मतलब है कि ये सभी प्रक्रियाएं एक ही लॉक के जारी होने की प्रतीक्षा कर रही हैं। जब सिस्टम (4) प्रक्रिया लॉक जारी करती है (3,368 सेकंड के लिए रखने के बाद!), प्रतीक्षा प्रक्रियाएं, बदले में, इसे कैप्चर करती हैं, अपना छोटा काम करती हैं और लॉक को पास करती हैं। प्रतीक्षा कतार में लगभग सौ प्रक्रियाएं हैं, जो एकल लॉक के प्रभाव की डिग्री को दर्शाती है।

रेडी थ्रेड स्टैक के एक छोटे से अध्ययन से पता चला है कि ज्यादातर उम्मीदें कर्नेलबेस डी.एलडाइटफाइल से आती हैं। मैंने WPA को इस फ़ंक्शन के कॉलर्स को समूहीकरण के साथ प्रदर्शित करने के लिए कहा। वहां आप देख सकते हैं कि इस कैथारिसिस के 12 मिलीसेकंड में 174 धागे राइटफाइल प्रतीक्षा से बाहर निकलते हैं, और उन्होंने औसतन 1,184 सेकंड इंतजार किया:


174 थ्रेड्स WriteFile की प्रतीक्षा कर रहे हैं, औसत प्रतीक्षा समय 1,184 सेकंड

यह एक अद्भुत अंतराल है, और वास्तव में, समस्या की पूरी सीमा भी नहीं, क्योंकि कर्नेलबेस जैसे अन्य कार्यों के कई धागे ! GetQueuedCompletionStatus, एक ही लॉक की रिहाई की उम्मीद करते हैं।

सिस्टम क्या करता है (4)

इस बिंदु पर, मुझे पता था कि निर्माण प्रगति बंद हो गई क्योंकि सभी कंपाइलर प्रक्रियाएं और अन्य लोग WriteFile की उम्मीद कर रहे थे, क्योंकि सिस्टम (4) ने ताला लगा रखा था। एक अन्य रेडी थ्रेड आईडी कॉलम ने दिखाया कि थ्रेड 3276 ने सिस्टम प्रोसेस में लॉक को रिलीज़ किया।

असेंबली के सभी "हैंग" के दौरान, थ्रेड 3276 100% लोड किया गया था, इसलिए यह स्पष्ट है कि लॉक को पकड़ते समय सीपीयू पर कुछ काम किया। सीपीयू समय कहाँ बिताया जाता है, यह जानने के लिए, आइए थ्रेड 3276 के लिए सीपीयू उपयोग (नमूना) ग्राफ देखें। सीपीयू उपयोग डेटा आश्चर्यजनक रूप से स्पष्ट था। लगभग हर समय यह एक फ़ंक्शन का काम लेता है ntoskrnl.exe! RtlFindNextForwardRunClear (नमूनों की संख्या स्तंभों में संख्याओं के साथ इंगित की गई है):


कॉल स्टैक से ntoskrnl.exe! RtlFindNextForwardRunClear होता है

थ्रेड स्टैक को देखना रीडिंग थ्रेड आईडी ने पुष्टि की कि NtfsCheckpointVolume ने 3.368 के बाद लॉक जारी किया है:


स्टैक को NtfsCheckpointVolume से ExReleaseResourceLite पर कॉल करें

इस समय, यह मुझे लग रहा था कि ट्विटर पर मेरे अनुयायियों के समृद्ध ज्ञान का उपयोग करने का समय है, इसलिए मैंने इस प्रश्न को पोस्ट किया और एक पूर्ण कॉल स्टैक दिखाया। यदि आप पर्याप्त जानकारी प्रदान करते हैं तो ऐसे प्रश्नों के साथ ट्वीट बहुत प्रभावी हो सकते हैं।

इस मामले में, कैटलिन गर्ड का सही उत्तर बहुत जल्दी और कई अन्य शानदार सुझावों के साथ आया। उसने सिस्टम रिकवरी सुविधा को बंद कर दिया - और अचानक निर्माण दो से तीन गुना तेज हो गया!

लेकिन रुकिए, आगे और भी बेहतर है

पूरे सिस्टम में 3+ सेकंड के लिए निष्पादन को रोकना काफी प्रभावशाली है, लेकिन यदि आप सीपीयू उपयोग (नमूना) तालिका में पता स्तंभ जोड़ते हैं और इसके द्वारा सॉर्ट करते हैं तो स्थिति और भी प्रभावशाली है। यह दिखाता है कि वास्तव में RtlFindNextForwardRunClear नमूने कहाँ मिलते हैं - और उनमें से 99% एक निर्देश पर गिरते हैं!



मैंने ntoskrnl.exe और ntkrnlmp.pdb फाइलें (अपने दोस्त के समान संस्करण) dumpbin /disasm और dumpbin /disasm को dumpbin /disasm में रुचि के कार्य को देखने के लिए चलाया। पतों के पहले अंक अलग-अलग हैं क्योंकि कोड बूट पर चलता है, लेकिन अंतिम चार हेक्स मान समान हैं (वे ASLR के बाद नहीं बदलते हैं):

  RtlFindNextForwardRunClear:
 ...
 14006464F: 4 सी 3 बी सी 3 सीएमपी आर 8, आरबीएक्स
 140064652: 73 0F jae 0000000140064663
 140064654: 41 39 28 सीएमपी डॉर्ड पीटीआर [आर 8], ईबीपी
 140064657: 75 0A jne 0000000140064663
 140064659: 49 83 C0 04 r8.4 जोड़ें
 14006465D: 41 83 C1 20 r9d, 20h जोड़ें
 140064661: EB EC jmp 000000014006464F
 ... 

हम देखते हैं कि ... 4657 सात निर्देशों के एक चक्र में शामिल है, जो अन्य नमूनों में पाए जाते हैं। ऐसे नमूनों की संख्या दाईं ओर इंगित की गई है:

  RtlFindNextForwardRunClear:
 ...
 14006464F: 4 सी 3 बी सी 3 सीएमपी आर 8, आरबीएक्स 4
 140064652: 73 0F jae 0000000140064663 41
 140064654: 41 39 28 सीएमपी डॉर्ड पीटीआर [आर 8], ईबीपी     
 140064657: 75 0A jne 0000000140064663 7498
 140064659: 49 83 C0 04 जोड़ें r8.4 2
 14006465D: 41 83 C1 20 r9d, 20h 1 जोड़ें
 140064661: EB EC jmp 000000014006464F 1
 ... 

पाठक के लिए एक अभ्यास के रूप में, आइए हम निर्देशों के असाधारण निष्पादन के साथ सुपरसेलकर प्रोसेसर पर नमूनों की संख्या की व्याख्या छोड़ दें, हालांकि इस लेख में कुछ अच्छे विचार मिल सकते हैं। इस मामले में, हमारे पास एक 32-कोर एएमडी राईजन थ्रेडिपर 2990WX है। जाहिर है, एक समय में पांच निर्देशों के निष्पादन के साथ माइक्रो-अप फ्यूजन का प्रोसेसर फ़ंक्शन वास्तव में प्रत्येक चक्र को jne पर पूरा करने की अनुमति देता है, क्योंकि चयन के बाद सबसे महंगी निर्देश के बहुमत में आने के बाद अनुदेश।

तो यह पता चला है कि 64 तार्किक प्रोसेसर वाली एक मशीन सात महत्वपूर्ण प्रक्रियाओं के चक्र में रुक जाती है, जबकि एक महत्वपूर्ण NTFS लॉक को पकड़े हुए है, जो सिस्टम रिकवरी को अक्षम करके तय किया गया है।

कोडा

यह स्पष्ट नहीं है कि इस कोड ने इस विशेष मशीन पर बुरा व्यवहार क्यों किया। मुझे लगता है कि यह किसी तरह लगभग खाली 2 टीबी डिस्क पर डेटा के वितरण से संबंधित है। जब सिस्टम रिकवरी को वापस चालू किया गया था, तो समस्या भी वापस आ गई, लेकिन इतनी गंभीर नहीं। हो सकता है कि खाली जगह के विशाल टुकड़े के साथ डिस्क के लिए किसी प्रकार का विकृति है?

ट्विटर पर एक अन्य अनुयायी ने विंडोज 7 से वॉल्यूम शैडो कॉपी बग का उल्लेख किया, जो ओ (एन ^ 2) के दौरान निष्पादन की अनुमति देता है। यह त्रुटि कथित रूप से विंडोज 8 में तय की गई थी, लेकिन इसे किसी रूप में संरक्षित किया गया हो सकता है। मेरे स्टैक के निशान स्पष्ट रूप से दिखाते हैं कि VspUpperFindNextForwardRunClearLimited (इस 16 मेगाबाइट क्षेत्र में एक प्रयोग किया गया बिट ढूंढना ) VspUpperFindNextForwardRunClear (कहीं भी अगले उपयोग किए गए बिट की तलाश में है, लेकिन यह निर्दिष्ट क्षेत्र के बाहर है तो वापस नहीं आता है)। बेशक, यह एक निश्चित समझदारी का कारण बनता है। जैसा कि मैंने हाल ही में कहा , O (n ^ 2) खराब स्केलेबल एल्गोरिदम का कमजोर बिंदु है। दो कारक यहां मेल खाते हैं: ऐसा कोड उत्पादन में लाने के लिए पर्याप्त तेज है, लेकिन इस उत्पादन को छोड़ने के लिए काफी धीमा है।

ऐसी रिपोर्टें थीं कि फ़ाइलों के बड़े पैमाने पर हटाने के साथ एक समान समस्या होती है, लेकिन हमारे ट्रेस में बहुत सारे विलोपन नहीं दिखाई देते हैं, इसलिए समस्या, जाहिरा तौर पर, यह नहीं है।

अंत में, मैं लेख की शुरुआत से सिस्टम-वाइड सीपीयू लोड शेड्यूल की नकल करूँगा, लेकिन इस बार सिस्टम समस्या प्रक्रिया द्वारा सीपीयू के उपयोग को इंगित करता है (नीचे हरे रंग में)। ऐसी तस्वीर में, समस्या पूरी तरह से स्पष्ट है। सिस्टम की प्रक्रिया तकनीकी रूप से शीर्ष ग्राफ पर दिखाई देती है, लेकिन इस पैमाने पर याद करना आसान है।



यद्यपि यह समस्या ग्राफ पर स्पष्ट रूप से दिखाई देती है, यह वास्तव में कुछ भी नहीं साबित करता है। जैसा कि वे कहते हैं , सहसंबंध एक कारण संबंध नहीं है। केवल संदर्भ स्विचिंग घटनाओं के विश्लेषण से पता चलता है कि यह वह धारा है जो महत्वपूर्ण लॉक रखती है - और फिर आप यह सुनिश्चित कर सकते हैं कि हमें वास्तविक कारण मिल गया है, न कि केवल एक यादृच्छिक सहसंबंध।

अनुरोध

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

यदि Microsoft पर NTFS टीम का कोई व्यक्ति इस विषय पर बात करना चाहता है, तो मुझे बताएं, और मैं आपको मूल रिपोर्ट के लेखक के साथ कनेक्ट कर सकता हूं और ETW ट्रेस प्रदान कर सकता हूं।

संदर्भ

• मूल ट्विटर धागा
  
• ट्विटर पोस्ट की घोषणा
  
• हैकर समाचार पर चर्चा
  
• रेडिट पर चर्चा
  
• संभवतः प्रासंगिक Windows / NTFS tirade