विंडोज़ को लंबे समय तक फ़ाइल संचालन की सुस्ती और प्रक्रियाओं के निर्माण के लिए दोषी ठहराया गया है। क्या आपने कभी उन्हें धीमा बनाने की कोशिश की है? यह आलेख विंडोज (विज्ञापन infinitum) में प्रक्रियाओं के निर्माण को धीरे-धीरे धीमा करने की तकनीक दिखाएगा, जो कि अधिकांश उपयोगकर्ताओं के लिए अदृश्य रूप से होगी!

और निश्चित रूप से, लेख आपको यह भी बताएगा कि इस समस्या का पता कैसे लगाया जाए और कैसे बचा जाए।

यह एक वास्तविक समस्या है जो मुझे वर्ष की शुरुआत में मिली थी, और लेख बताता है कि मैंने इसे कैसे खोजा और इसे एक हल मिला। विंडोज धीमा करने पर पिछले लेख:

• विंडोज को धीमा करना, भाग 0: VirtualAlloc का मनमाना मंदी
• विंडोज को धीमा करना, भाग 1: फ़ाइल का उपयोग

कुछ गड़बड़ है

मैं परेशानी की तलाश में नहीं हूं, लेकिन मुझे लगता है कि मैंने उन्हें ढूंढ लिया। शायद इसलिए कि मैं सप्ताहांत में सैकड़ों बार स्रोत से क्रोम इकट्ठा करता हूं, या मैं जीवन में अशुभ हूं। मुझे लगता है कि हम कभी नहीं जान पाएंगे। एक तरह से या किसी अन्य, इस लेख में पांचवें गंभीर समस्या का वर्णन किया गया है जो मैंने क्रोम के निर्माण के दौरान विंडोज में सामना किया था।

1. अनियोजित क्रमांकन, जो संपूर्ण हैंग UI की ओर जाता है: "24-कोर प्रोसेसर, लेकिन मैं कर्सर को स्थानांतरित नहीं कर सकता । "
2. विंडोज़ के लिए माइक्रोसॉफ्ट के ऐड-ऑन में से एक में एक प्रक्रिया डिस्क्रिप्टर लीक: "ज़ोंबी प्रक्रिया आपकी मेमोरी को खा जाती है । "
3. विंडोज फ़ाइल कैश में लंबे समय तक सही त्रुटि: "कंपाइलर त्रुटि? लिंकर त्रुटि? विंडोज कर्नेल बग। "
4. फ़ाइल सूचनाओं का गलत तरीके से उपयोग करने पर प्रदर्शन विफलता: "विंडोज को धीमा करना, भाग 1: फ़ाइल का उपयोग । "
5. और यह: एक अजीब वास्तु समाधान जो समय के साथ प्रक्रियाओं के निर्माण को धीमा कर देता है।

दुर्लभ दुर्घटना ट्रैकिंग

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

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

लेकिन जब मैं बाद में आया, तो विधानसभा पूरी तरह से बंद हो गई। लगभग 7000 विधानसभा चरणों के बाद, कोई प्रगति ध्यान देने योग्य नहीं थी।

ओ (एन ^ 2) आमतौर पर अच्छा नहीं होता है

अनुप्रयोग सत्यापनकर्ता लॉग फ़ाइलों को बनाना पसंद करता है। और कोई फर्क नहीं पड़ता कि कोई भी इन फ़ाइलों को नहीं देख रहा है, वह उन्हें केवल मामले में बनाता है। और इन फ़ाइलों में अद्वितीय नाम होने चाहिए। मुझे यकीन है कि यह सिर्फ एक अच्छा विचार था जैसा कि आरोही क्रम में लॉग को संख्यात्मक नाम देना है, जैसे कि gomacc.exe.0.dat, gomacc.exe.1.dat, और इसी तरह।

आरोही क्रम में संख्यात्मक नाम प्राप्त करने के लिए, आपको यह निर्धारित करने की आवश्यकता है कि आगे किस संख्या का उपयोग करना है। सबसे आसान तरीका संभव नाम / संख्याओं का प्रयास करना है जब तक कि आप एक ऐसा नहीं पाते हैं जो अभी तक उपयोग नहीं किया गया है। यही है, gomacc.exe.0.dat नामक एक नई फ़ाइल बनाने का प्रयास करें, और यदि यह पहले से मौजूद है, तो gomacc.exe.1.dat और इसी तरह प्रयास करें।

क्या गलत हो सकता है?

वास्तव में, सबसे खराब स्थिति में, सब कुछ बहुत बुरा है

यह पता चला है कि यदि आप एक प्रक्रिया बनाते समय अप्रयुक्त फ़ाइल नाम के लिए एक रेखीय खोज करते हैं, तो एन प्रक्रियाओं को शुरू करने में ओ (एन ^ 2) संचालन लगता है। सामान्य ज्ञान यह निर्धारित करता है कि O (N ^ 2) एल्गोरिदम बहुत धीमे हैं यदि आप गारंटी नहीं दे सकते कि N हमेशा अपेक्षाकृत छोटा रहता है।

स्थिति कितनी खराब हो जाएगी यह इस बात पर निर्भर करता है कि फ़ाइल के अस्तित्व को सत्यापित करने में कितना समय लगता है। मैंने माप लिया और पाया कि विंडोज पर लगभग 80 माइक्रोसेकंड (80 μs या 0.08 ms) लगते हैं। पहली प्रक्रिया शुरू करना त्वरित है, लेकिन 1000 वीं प्रक्रिया शुरू करने के लिए 1000 पहले से निर्मित लॉग फ़ाइलों को स्कैन करने की आवश्यकता होती है। यह 80 एमएस लेता है, और फिर और भी अधिक।

Chrome के एक विशिष्ट निर्माण में कंपाइलर को लगभग 30,000 बार चलाने की आवश्यकता होती है। कंपाइलर के प्रत्येक रन के लिए प्रत्येक फ़ाइल की जाँच के लिए पहले से बनाई गई लॉग फ़ाइलों, 0.08 एमएस की स्कैनिंग की आवश्यकता होती है। अगले उपलब्ध लॉग फ़ाइल नाम के लिए एक रेखीय खोज का मतलब है कि एन प्रक्रियाओं को चलाने के लिए (एन ^ 2) / 2 फ़ाइल के अस्तित्व की जांच करनी है, अर्थात 30,000 * 30,000 / 2, जो 450 मिलियन है। चूँकि किसी फ़ाइल के अस्तित्व का प्रत्येक सत्यापन 0.08 एमएस लेता है, यह 36 मिलियन मिलीसेकंड या 36,000 सेकंड है। यही है, क्रोम का निर्माण समय, जो आमतौर पर पांच से दस मिनट है, एक और दस घंटे तक बढ़ जाएगा।

अरे।

इस लेख को लिखते समय, मैंने लगभग 7000 बार एक खाली निष्पादन योग्य फ़ाइल चलाकर त्रुटि को पुन: उत्पन्न किया - और इस तरह एक स्पष्ट O (n ^ 2) वक्र देखा:



अजीब तरह से पर्याप्त है, अगर आप ETW ट्रेस लेते हैं और औसत CreateFile कॉल समय को देखते हैं, तो लगभग सभी फाइलों के लिए परिणाम पांच माइक्रोसेकंड से कम है (औसत उदाहरण में 4.386 μs नीचे)



ऐसा प्रतीत होता है कि यह फ़ाइल I / O ट्रेसिंग पर केवल ETW प्रतिबंध दिखाता है। फ़ाइल I / O ईवेंट केवल फ़ाइल सिस्टम के सबसे निचले स्तर को ट्रैक करते हैं, और Ntfs.sys के ऊपर FLTMGR.SYS और ntoskrnl.exe सहित कई और स्तर हैं। हालाँकि, मंदी पूरी तरह से छिपी नहीं हो सकती है - CPU उपयोग ग्राफ़ पर CPU उपयोग दिखाई देता है। नीचे दिया गया स्क्रीनशॉट 548 एमएस के समय अंतराल को दर्शाता है, जो एकल प्रक्रिया के निर्माण का प्रतिनिधित्व करता है। मूल रूप से, लगभग 6850 संभव लॉग फ़ाइल नामों को स्कैन करने में हर समय लगता है:

क्या अधिक उत्पादक डिस्क मदद करेगी?

नहीं।

संसाधित डेटा की मात्रा छोटी है, और डिस्क पर लिखने की मात्रा भी कम है। बग को पुन: पेश करने के लिए मेरे परीक्षणों के दौरान, डिस्क लगभग पूरी तरह से निष्क्रिय थी। यह समस्या CPU से संबंधित है क्योंकि सभी प्रासंगिक डिस्क डेटा कैश हैं। और भले ही ओवरहेड लागत को परिमाण के एक क्रम से कम किया गया था, फिर भी वे बहुत बड़े होंगे। आप O (N ^ 2) एल्गोरिथ्म में सुधार नहीं कर सकते।

खोज

.Dat फ़ाइलों के लिए% userprofile% \ appverifierlogs खोज कर इस विशेष समस्या का पता लगाया जा सकता है। सामान्य तौर पर, आप ETW ट्रेस की जांच करके प्रक्रिया निर्माण में मंदी का पता लगा सकते हैं, और अब आप जानते हैं कि क्या देखना है।

निर्णय

सबसे आसान उपाय लॉगिंग को बंद करना है। यह लॉग के गीगाबाइट के साथ डिस्क को भरना भी बंद कर देगा। यह निम्नलिखित कमांड द्वारा अक्षम है:

appverif.exe -logtofile disable

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

• आम तौर पर 200 प्रति सेकंड (5 एमएस प्रति प्रक्रिया)
• आवेदन सत्यापनकर्ता के साथ 75 प्रति सेकंड सक्षम लेकिन लॉगिंग अक्षम (13 एमएस प्रति प्रक्रिया)
• आवेदन सत्यापनकर्ता के साथ 40 प्रति सेकंड और पहले लॉगिंग चालू हुआ ... (25 एमएस प्रति प्रक्रिया, समय धीरे-धीरे अनंत तक बढ़ जाता है)
• क्रोम के निर्माण के बाद 0.4 प्रति सेकंड

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

लेकिन एप्लिकेशन सत्यापनकर्ता अब समर्थित नहीं है, और लॉग फ़ाइलें वैसे भी बेकार हैं, इसलिए बस उन्हें अक्षम करें।

सहायक सूचना

रिक्त फ़ाइलें और बग को फिर से बनाने के लिए एक स्क्रिप्ट।

प्रयोग के अंत के आसपास से ETW ट्रेस यहां है ।

अन्य लिंक:

चार्ट बनाने के लिए उपयोग किया जाने वाला कच्चा समय डेटा।

रेडिट पर चर्चा

हैकर समाचार पर चर्चा

अन्य O (n ^ 2) के उदाहरण के लिए एल्गोरिदम जो पैडलिंग कर रहे हैं, एक्सीडेंटली क्वाड्रेटिक देखें

अधिक सांसारिक आनंद के लिए, सितंबर में काम करने के लिए मेरे 19 अलग-अलग तरीकों का एक वीडियो संकलन देखें - मैं इस महीने प्रयोग जारी रखने के लिए बहुत व्यस्त था।