विंडोज पार्ट 3 को धीमा करना: प्रक्रिया समाप्ति



लेखक Google पर Chrome के प्रदर्शन को अनुकूलित करने में लगा हुआ है - लगभग। प्रति।

2017 की गर्मियों में, मैंने विंडोज के प्रदर्शन के मुद्दे के साथ संघर्ष किया। प्रक्रिया समाप्ति धीमी, क्रमबद्ध और सिस्टम इनपुट कतार को अवरुद्ध करती थी, जिसके कारण क्रोम असेंबली के दौरान माउस कर्सर के कई फ्रीज हो जाते थे। मुख्य कारण यह था कि प्रक्रियाओं के अंत में, विंडोज ने जीडीआई वस्तुओं की खोज में बहुत समय बिताया, जबकि सिस्टम-ग्लोबल यूज़र 32 के महत्वपूर्ण खंड को दबाए रखा। मैंने इस बारे में "24-कोर प्रोसेसर" लेख में बात की थी , लेकिन मैं कर्सर को स्थानांतरित नहीं कर सकता ।

Microsoft ने बग को ठीक कर दिया, और मैं अपने व्यवसाय में लौट आया, लेकिन फिर यह पता चला कि बग वापस आ गया है। लगातार इनपुट हैंग होने के साथ, एलएलवीएम परीक्षणों के धीमे संचालन के बारे में शिकायतें थीं।

लेकिन वास्तव में, बग वापस नहीं आया। कारण हमारे कोड में बदलाव था।

2017 का अंक

प्रत्येक Windows प्रक्रिया में कई मानक GDI ऑब्जेक्ट विवरणक होते हैं। ग्राफिक्स के साथ कुछ भी नहीं करने वाली प्रक्रियाओं के लिए, ये वर्णनकर्ता आमतौर पर NULL होते हैं। प्रक्रिया के अंत में, विंडोज इन विवरणकों के लिए कुछ फ़ंक्शन कहता है, भले ही वे NULL हों। इससे कोई फर्क नहीं पड़ा - सुविधाओं ने तेजी से काम किया - विंडोज 10 वर्षगांठ संस्करण की रिलीज तक, जिसमें कुछ सुरक्षा परिवर्तनों ने इन सुविधाओं को धीमा कर दिया । ऑपरेशन के दौरान, उन्होंने उसी लॉक को रखा जिसका उपयोग इनपुट इवेंट के लिए किया गया था। जब एक ही समय में बड़ी संख्या में प्रक्रियाएं समाप्त हो जाती हैं, तो हर कोई इस महत्वपूर्ण लॉक को धीमा करने वाले फ़ंक्शन को कई कॉल करता है, जो अंततः उपयोगकर्ता इनपुट को अवरुद्ध करता है और कर्सर जमा देता है।

Microsoft का पैच GDI ऑब्जेक्ट्स के बिना प्रक्रियाओं के लिए इन फ़ंक्शन को कॉल करने के लिए नहीं था। मैं विवरण नहीं जानता, लेकिन मुझे लगता है कि Microsoft पैच कुछ इस तरह था:

+ if (IsGUIProcess())
+ NtGdiCloseProcess();
– NtGdiCloseProcess();

यदि प्रक्रिया GUI / GDI प्रक्रिया नहीं है, तो बस GDI सफाई छोड़ें।

चूंकि संकलक और अन्य प्रक्रियाएं जो हम जल्दी से बनाते हैं और समाप्त करते हैं, उन्होंने GDI ऑब्जेक्ट का उपयोग नहीं किया, यह पैच UI की ठंड को ठीक करने के लिए पर्याप्त निकला।

2018 का अंक

यह पता चला कि प्रक्रियाएं बहुत आसानी से कुछ मानक जीडीआई वस्तुओं को आवंटित की जाती हैं। यदि आपकी प्रक्रिया gdi32.dll को लोड करती है, तो आप स्वचालित रूप से GDI ऑब्जेक्ट (DC, सतहों, क्षेत्रों, ब्रश, फोंट, आदि) को प्राप्त करेंगे, चाहे आपको उनकी आवश्यकता हो या नहीं (ध्यान दें कि ये मानक GDI ऑब्जेक्ट टास्क मैनेजर में प्रदर्शित नहीं होते हैं इस प्रक्रिया के लिए GDI वस्तुओं में से)।

लेकिन यह एक समस्या नहीं होनी चाहिए। मेरा मतलब है, क्यों संकलक gdi32.dll लोड होगा? ठीक है, यह पता चला है कि यदि आप user32.dll, shell32.dll, ole32.dll या कई अन्य DLL लोड करते हैं, तो आप स्वचालित रूप से अतिरिक्त gdi32.dll (उपरोक्त मानक GDI ऑब्जेक्ट्स के साथ) प्राप्त करेंगे। और इन पुस्तकालयों में से किसी एक को गलती से डाउनलोड करना बहुत आसान है।

LLLM परीक्षण जब CommandLineToArgvW (shell32.dll) नामक प्रत्येक प्रक्रिया को लोड करता है, और कभी-कभी SHGetKnownFolderPath (भी shell32.dll) कहा जाता है। ये कॉल gdi32.ll को खींचने और इन डरावने मानक GDI ऑब्जेक्ट्स को उत्पन्न करने के लिए पर्याप्त थे। चूंकि एलएलवीएम टेस्ट सूट इतनी सारी प्रक्रियाएं उत्पन्न करता है, इसलिए यह अंततः प्रक्रियाओं के पूरा होने पर क्रमबद्ध हो जाता है, जिससे भारी देरी और इनपुट से मुक्त हो जाता है, जो 2017 में बहुत खराब थे।

लेकिन इस बार हमें ब्लॉकिंग के साथ मुख्य समस्या के बारे में पता था, इसलिए हमें तुरंत पता था कि क्या करना है।

सबसे पहले, हमने कमांड लाइन को कमांड लाइन को मैन्युअल रूप से पार्स करने के लिए कमांडलाइनटॉअर्गव को कॉल करने से छुटकारा दिया। उसके बाद, LLVM परीक्षण सूट ने शायद ही कभी किसी समस्याग्रस्त DLL से किसी भी फ़ंक्शन को बुलाया। लेकिन हम पहले से जानते थे कि यह किसी भी तरह से प्रदर्शन को प्रभावित नहीं करेगा। कारण यह था कि यहां तक ​​कि शेष सशर्त कॉल हमेशा shell32.dll को खींचने के लिए पर्याप्त था, जो बदले में gdi32.dll को खींचता था, जो मानक GDI ऑब्जेक्ट बनाता है।

दूसरा फिक्स शेल 32.ll की लोडिंग में देरी थी। विलंबित लोडिंग का मतलब है कि पुस्तकालय मांग पर लोड करता है - जब फ़ंक्शन कहा जाता है - प्रक्रिया शुरू होने पर लोड करने के बजाय। इसका मतलब यह था कि shell32.dll और gdi32.dll शायद ही कभी लोड होता है, और हमेशा नहीं।

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

कभी-कभी छोटे बदलावों का सबसे बड़ा परिणाम होता है। आपको बस "शून्य" डायल करने की आवश्यकता है।

निष्पादन मार्ग स्वीकार नहीं किया गया

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

 int main(int argc, char* argv[]) { if (argc < 0) { CommandLineToArgvW(nullptr, nullptr); // shell32.dll, pulls in gdi32.dll } } 

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

पैथोलॉजी प्रजनन

जब मैंने प्रारंभिक त्रुटि की जांच की, तो मैंने एक कार्यक्रम ( ProcessCreateTests ) लिखा, जिसने 1000 प्रक्रियाएं बनाईं और फिर उन सभी को समानांतर में मार दिया। यह फ्रीज को पुन: पेश करता है, और जब Microsoft ने त्रुटि को ठीक किया, तो मैंने पैच की जांच करने के लिए एक परीक्षण कार्यक्रम का उपयोग किया: वीडियो देखें। बग के पुनर्जन्म के बाद, मैंने -user32 विकल्प को जोड़कर अपने कार्यक्रम को बदल दिया, जो हजारों परीक्षण प्रक्रियाओं में से प्रत्येक के लिए user32.dll को लोड करता है। जैसा कि अपेक्षित था, इस विकल्प के साथ सभी परीक्षण प्रक्रियाओं का पूरा होने का समय नाटकीय रूप से बढ़ जाता है, और माउस कर्सर फ्रीज का पता लगाना आसान होता है। प्रक्रिया निर्माण समय -user32 विकल्प के साथ भी बढ़ जाता है, लेकिन प्रक्रिया निर्माण के दौरान कोई कर्सर निलंबन नहीं हैं। आप इस कार्यक्रम का उपयोग कर सकते हैं और देख सकते हैं कि समस्या कितनी भयानक हो सकती है। अपटाइम के एक सप्ताह के बाद मेरे चार-कोर / आठ-थ्रेडेड नोटबुक के कुछ विशिष्ट परिणाम हैं। -User32 विकल्प सब कुछ के लिए समय बढ़ाता है, लेकिन प्रक्रियाओं पर UserCrit लॉक विशेष रूप से नाटकीय रूप से समाप्त हो जाता है:

> ProcessCreatetests.exe
Process creation took 2.448 s (2.448 ms per process).
Lock blocked for 0.008 s total, maximum was 0.001 s.

Process destruction took 0.801 s (0.801 ms per process).
Lock blocked for 0.004 s total, maximum was 0.001 s.

> ProcessCreatetests.exe -user32
Testing with 1000 descendant processes with user32.dll loaded.
Process creation took 3.154 s (3.154 ms per process).
Lock blocked for 0.032 s total, maximum was 0.007 s.

Process destruction took 2.240 s (2.240 ms per process).
Lock blocked for 1.991 s total, maximum was 0.864 s.

सिर्फ मनोरंजन के लिए गहरी खुदाई

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

श्रृंखला के अन्य लेख:

• विंडोज को धीमा करना, भाग 0: VirtualAlloc का मनमाना मंदी
• विंडोज को धीमा करना, भाग 1: फ़ाइल का उपयोग
• विंडोज पार्ट 2 को धीमा करना: प्रोसेस बनाना
• विंडोज को धीमा करना, भाग 3: यह

साहित्य

• पहली UI सस्पेंशन रिपोर्ट: "24-कोर प्रोसेसर, लेकिन मैं कर्सर को स्थानांतरित नहीं कर सकता"
• निम्नलिखित लेख, जो समस्या की समझ की ओर जाता है: "इस लॉक को पकड़ते समय विंडोज क्या करता है"
• Gmail, ASLR v8 कार्यकर्ताओं, CFG मेमोरी आवंटन नीति और धीमी WMI स्कैनिंग के बीच बातचीत के कारण एक और UI ब्लॉक के बारे में एक लेख: "24-कोर सीपीयू, लेकिन मैं एक ईमेल टाइप नहीं कर सकता"
• कंपाइलर लोडिंग gdi32.dll अजीब लगता है, लेकिन यह और भी अजीब है कि कंपाइलर mshtml.dll को लोड करता है, जो VC ++ कुछ मामलों में करता था
• कभी-कभी अनुसंधान के कुछ सप्ताह छोटे लेकिन महत्वपूर्ण परिवर्तनों की ओर ले जाते हैं, जैसा कि लेख में "जीरो डायल करने के लिए जानना" पर चर्चा की गई है।
• बग फिक्स को सत्यापित करने के लिए ProcessCreateTests और ETW के उपयोग को प्रदर्शित करने वाला वीडियो
• मैनुअल कमांड लाइन पार्सिंग द्वारा एलएलवीएम के लिए पहला परिवर्तन
• LL32M के लिए दूसरा फिक्स शेल 32. लोड लोड विलंब का उपयोग करना