निष्क्रिय अवस्था में शांति: ऑप्टिमाइज़ेशन से पहले और बाद में Windows की पृष्ठभूमि गतिविधि

संक्षिप्त उत्तर

Windows के पृष्ठभूमि घटकों को अक्षम करने से निष्क्रिय अवस्था वास्तव में शांत होती है: माप की दो स्वतंत्र श्रृंखलाओं में प्रक्रियाओं की संख्या 49–56 % घटी, निष्क्रिय अवस्था में CPU उपयोग 17–67 % घटा, और दूसरी श्रृंखला में मेमोरी कमिट (commit) की मात्रा 52 % घटी। लेकिन पूर्ण CPU लोड के तहत थ्रूपुट केवल 0,2–0,5 % बढ़ा। «शांत निष्क्रिय अवस्था» का अर्थ पृष्ठभूमि कार्य और संसाधनों के लिए प्रतिस्पर्धा में प्रमाणित कमी है, FPS में वृद्धि नहीं: इस अध्ययन में गेमिंग पर अंतिम प्रभाव नहीं मापा गया।

स्थिति: प्रभाव की दिशा को वर्चुअल मशीन में Windows 11 के एक ही बिल्ड पर दो स्वतंत्र श्रृंखलाओं में दोहराया गया। श्रृंखलाओं के बीच परिमाण अलग-अलग हैं, क्योंकि Windows का पृष्ठभूमि कार्य उछालों में आता है: Microsoft Defender स्कैनिंग वाले समयखंड में CPU उपयोग का अंतर −67 % तक पहुँचता है, जबकि पहले से शांत समयखंड में यह −17 % है।

जाँच योग्य दावा

हमने चार दावों की जाँच की:

1. पृष्ठभूमि घटकों को अक्षम करने से निष्क्रिय अवस्था में सिस्टम की गतिविधि उल्लेखनीय रूप से घटती है।
2. इससे बूट के बाद के शुरुआती मिनटों में गतिविधि उल्लेखनीय रूप से घटती है।
3. इससे मेमोरी की खपत उल्लेखनीय रूप से घटती है।
4. इससे पूर्ण CPU लोड के तहत प्रदर्शन में मापने योग्य वृद्धि होती है।

अध्ययन का दायरा

• Windows 11 Pro, build 26300.9457 (26H2);
• वर्चुअल मशीन: 4 vCPU, 8 GB RAM, VMware वर्चुअलाइज़ेशन;
• एक ही इंस्टॉलेशन की दो स्थितियाँ: मूल («पहले») और BoosterX अनुकूलन प्रोफ़ाइल लागू करने के बाद (माप की तारीखों पर उपलब्ध नवीनतम बिल्ड);
• माप की दो स्वतंत्र श्रृंखलाएँ: 2026-09-18 और 2026-09-19; स्थितियों की तुलना डिस्क की स्वतंत्र प्रतियों पर की गई, ताकि माप एक-दूसरे को प्रभावित न करें;
• चरण: बूट के बाद 5 मिनट, स्थिर होने के लिए 5 मिनट, निष्क्रिय अवस्था में 5 मिनट;
• छोटी सिंथेटिक लोड जाँचें: 1, 4 और 8 थ्रेड, मेमोरी लोड, समयांतराल वाली लोड और प्राथमिकताओं के मिश्रण।

माप में वास्तविक गेम, GPU लोड, भौतिक हार्डवेयर और लंबे समयखंड (घंटे और दिन) शामिल नहीं थे।

चार चरणों और गेमिंग मापों वाली Ryzen 7 7800X3D भौतिक PC पर एक अलग श्रृंखला, «BoosterX: Windows का पृष्ठभूमि कार्य और CS2 में FPS» लेख में प्रकाशित है। उसके परिणामों को वर्चुअल मशीनों वाली इस श्रृंखला के साथ नहीं जोड़ा गया है।

कार्यविधि

प्रोटोकॉल «हम Windows का अध्ययन कैसे करते हैं» के अनुरूप है:

• प्रत्येक चरण को ETW ट्रेसिंग (Windows Performance Recorder, CPU, डिस्क, फ़ाइलों और नेटवर्क के हल्के प्रोफ़ाइल) और प्रदर्शन काउंटरों के साथ रिकॉर्ड किया गया; अंतराल सिस्टम के लिए 5 सेकंड और प्रक्रियाओं के लिए 15 सेकंड था;
• «बूट के बाद» चरण नियंत्रित रीबूट से शुरू किया गया और लगभग एक मिनट के अपटाइम पर शामिल किया गया;
• प्रत्येक ट्रेस में खोई हुई घटनाओं की संख्या जाँची गई — यहाँ दिए गए सभी समयखंडों में यह शून्य है;
• औसत केवल चरण की सीमाओं के भीतर के पूर्ण पाँच-सेकंड अंतरालों पर निकाला गया (प्रति चरण 59 अंतराल);
• श्रृंखला 2 में «पहले» का पहला रन वर्चुअल मशीन के स्लीप में चले जाने के कारण बाहर रखा गया; दोबारा किया गया रन इस्तेमाल किया गया;
• लोड जाँचें दो-दो बार चलाई गईं और माध्यिकाएँ दी गई हैं; CPU उपयोग को चार vCPU के आधार पर सामान्यीकृत किया गया।

«पहले» और «बाद» Windows के एक ही इंस्टॉलेशन की स्थितियाँ हैं: «बाद» अनुकूलन प्रोफ़ाइल लागू करने से प्राप्त हुआ, जबकि «पहले» मूल स्थिति है। सेटिंग्स का पूरा समूह बदला गया, इसलिए किसी एक बदलाव के अलग-अलग योगदान का आकलन नहीं किया गया।

परिणाम

निष्क्रिय अवस्था

श्रृंखला 1 (2026-09-18) — बिना सक्रिय रखरखाव वाली स्थिर निष्क्रिय अवस्था:

मेट्रिक	पहले	बाद	बदलाव
CPU उपयोग, %	2,48	2,06	−17 %
DPC + ISR, % CPU	1,73	1,59	−8 %
संदर्भ स्विच, /सेकंड	469	381	−19 %
प्रक्रियाएँ (औसत)	134,9	69,3	−49 %
थ्रेड (औसत)	1 444,6	738,7	−49 %
सभी प्रक्रियाओं का कुल CPU, %	1,22	1,06	−13 %
उपलब्ध मेमोरी, MB	5 490	6 518	+1 028
डिस्क से पढ़ना, KB/सेकंड	22,6	24,4	+8 %
डिस्क पर लिखना, KB/सेकंड	311,3	262,1	−16 %
नेटवर्क (प्राप्ति), KB/सेकंड	132,6	2,2	−98 %
नेटवर्क (भेजना), KB/सेकंड	43,2	4,7	−89 %

श्रृंखला 2 (2026-09-19) — निष्क्रिय अवस्था का वही समयखंड, लेकिन «पहले» की स्थिति में Microsoft Defender की पृष्ठभूमि स्कैनिंग चल रही थी:

मेट्रिक	पहले	बाद	बदलाव
CPU उपयोग, %	33,37	11,03	−67 %
संदर्भ स्विच, /सेकंड	3 737	291	−92 %
प्रक्रियाएँ (औसत)	142,3	61,9	−56 %
थ्रेड (औसत)	1 494,7	637,1	−57 %
उपलब्ध मेमोरी, MB	5 174	6 653	+1 479
उपयोग की गई भौतिक मेमोरी, MB	3 017	1 538	−49 %
मेमोरी कमिट (commit), MB	2 617	1 249	−52 %
Nonpaged pool, MB	298,2	212,9	−29 %
Paged pool, MB	258,5	86,0	−67 %
DPC, % CPU	0,89	0,19	−78 %
डिस्क से पढ़ना, MB/सेकंड	7,42	0,01	−99,9 %
डिस्क पर लिखना, MB/सेकंड	4,57	0,23	−95,0 %

श्रृंखला 2 की निष्क्रिय अवस्था में दोनों स्थितियों में नेटवर्क गतिविधि लगभग नहीं थी (दर्जनों बाइट प्रति सेकंड), इसलिए उसके लिए नेटवर्क की पंक्तियाँ नहीं दी गई हैं। श्रृंखलाओं के बीच का अंतर विरोधाभास नहीं, बल्कि पृष्ठभूमि गतिविधि का गुण है: जब Windows रखरखाव कर रहा होता है, तो पृष्ठभूमि घटकों को अक्षम करने से अधिक बचत होती है; जब समयखंड पहले से शांत हो, तो कम।

बूट के बाद के शुरुआती मिनट

मेट्रिक	श्रृंखला 1 (पहले → बाद)	श्रृंखला 2 (पहले → बाद)
CPU उपयोग, %	3,42 → 2,59	14,62 → 11,88
संदर्भ स्विच, /सेकंड	1 114 → 600	1 257 → 393
प्रक्रियाएँ	132 → 74	139 → 64
थ्रेड	—	1 719 → 746
उपयोग की गई भौतिक मेमोरी, MB	—	2 821 → 1 581
उपलब्ध मेमोरी, MB	—	5 370 → 6 610
डिस्क से पढ़ना, KB/सेकंड	—	826 → 433
डिस्क पर लिखना, KB/सेकंड	634 → 418	709 → 298
नेटवर्क (प्राप्ति), KB/सेकंड	—	1,15 → ~0

डैश का अर्थ है कि इस श्रृंखला में उस चरण के लिए मेट्रिक रिकॉर्ड नहीं की गई।

प्रक्रियाओं और मेमोरी का विवरण

निष्क्रिय अवस्था में इन्वेंटरी का स्नैपशॉट (श्रृंखला 1):

	पहले	बाद
प्रक्रियाएँ	136	70
थ्रेड	1 679	842
कुल working set, MB	3 841	1 868
कुल private bytes, MB	1 524	660

अनुकूलन से पहले मेमोरी के सबसे बड़े उपभोक्ता: एंटीवायरस प्रक्रिया MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB)। अनुकूलन के बाद सूची में सबसे ऊपर explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) और StartMenuExperienceHost (106 MB) थे।

उपलब्ध मेमोरी 1,0–1,5 GB बढ़ी, जबकि कमिट (commit) की मात्रा 52 % घटी। इनमें से वास्तव में क्या «मुक्त» किया जा सकता है और प्रक्रियाओं के working set का योग खाली मेमोरी के बराबर क्यों नहीं है, इसकी व्याख्या «Windows में वास्तव में कितनी मेमोरी मुक्त की जा सकती है» में दी गई है।

पूर्ण लोड के तहत

छोटी सिंथेटिक जाँचें (श्रृंखला 2, दो दोहरावों की माध्यिकाएँ):

परिदृश्य	थ्रूपुट में बदलाव	CPU उपयोग: पहले / बाद
एक थ्रेड	+5,4 %	21,9 / 22,6 %
चार थ्रेड (पूर्ण)	+0,19 %	88,9 / 89,4 %
आठ थ्रेड (पूर्ण)	+0,50 %	88,9 / 88,8 %
मेमोरी लोड	+11,2 %	84,8 / 87,5 %
समयांतराल वाली (1 ms विराम)	+5,4 %	64,3 / 67,7 %
मिश्रित प्राथमिकताएँ	+8,5 %	21,2 / 22,5 %
पृष्ठभूमि प्राथमिकता	+77,1 %	38,8 / 65,2 %

पूर्ण चार-थ्रेड लोड के तहत उपयोगी प्रक्रिया को अनुकूलन से पहले और बाद, दोनों में चार vCPU की क्षमता का लगभग 89 % मिला। वर्चुअल मशीन में शेष ~11 % को हटाए जा सकने वाला «Windows शोर» नहीं कहा जा सकता: हाइपरवाइज़र की शेड्यूलिंग गेस्ट ट्रेसिंग में दिखाई नहीं देती। कार्य थ्रेड समान रूप से वितरित थे (उनके बीच कार्य की मात्रा में अंतर — 0,994–0,997), कोई थ्रेड भूखा नहीं रहा, और अनुकूलन के बाद निष्क्रिय अवस्था में CPU कतार लगभग खाली थी।

पृष्ठभूमि गतिविधि कहाँ जाती है

«पहले» स्थिति में मापे गए पृष्ठभूमि गतिविधि के स्रोत:

• एंटीवायरस स्कैनिंग — श्रृंखला 2 के समयखंड में मुख्य स्रोत: प्रक्रिया MsMpEng.exe ने निष्क्रिय अवस्था के पाँच मिनट के समयखंड में 212 CPU-सेकंड खर्च किए;
• मूल स्थिति में खोज सेवा, SysMain सेवा, टेलीमेट्री, प्रिंट स्पूलर और अन्य घटक चल रहे थे — अनुकूलन प्रोफ़ाइल लगभग 50 पृष्ठभूमि सेवाओं और 58 निर्धारित कार्यों को अक्षम स्थिति में ले जाती है;
• बूट के बाद गतिविधि के साथ Windows अपडेट ऑर्केस्ट्रेटर चलता है।

पृष्ठभूमि घटकों को अक्षम करने से पृष्ठभूमि गतिविधि पूरी तरह समाप्त नहीं होती: अनुकूलित स्थिति में ऐप संगतता मूल्यांकन चलता रहा (रखरखाव समयखंड में लगभग 3,7 ms CPU प्रति सेकंड), और स्थिर निष्क्रिय अवस्था में कुल शेष पृष्ठभूमि गतिविधि 4,8 ms CPU प्रति सेकंड थी — चार vCPU की क्षमता का लगभग 0,12 % (ट्रेसिंग से मापा गया)।

क्या पुष्ट हुआ

• दोहराया गया (दो स्वतंत्र श्रृंखलाएँ): प्रक्रियाओं की संख्या −49…−56 %, थ्रेड −49…−57 %, उपलब्ध मेमोरी +1,0–1,5 GB।
• मापा गया (श्रृंखला 2): निष्क्रिय अवस्था में commit −52 %; निष्क्रिय अवस्था में उपयोग की गई भौतिक मेमोरी −49 % और बूट के बाद के चरण में −44 %।
• मापा गया: निष्क्रिय अवस्था में CPU उपयोग शांत समयखंड में −17 % और स्कैनिंग वाले समयखंड में −67 %; संदर्भ स्विच क्रमशः −19 % और −92 %; DPC −78 % (श्रृंखला 2 का समयखंड); बूट के बाद गतिविधि दोनों श्रृंखलाओं में कम थी।
• मापा गया: पूर्ण CPU लोड के तहत थ्रूपुट में वृद्धि +0,19 % (4 थ्रेड) और +0,50 % (8 थ्रेड); अपूर्ण और मिश्रित लोड में +5,4 से +11,2 % तक।
• मापा गया: पृष्ठभूमि प्राथमिकता वाले वर्ग का लोड 77,1 % तेज हुआ — «पहले» स्थिति में उसका मुकाबला Windows के अपने पृष्ठभूमि कार्य से था, जिसमें एंटीवायरस स्कैनिंग भी शामिल थी।
• देखा गया: पृष्ठभूमि गतिविधि के मुख्य स्रोत एंटीवायरस स्कैनिंग, रखरखाव और संगतता कार्य थे; अनुकूलन के बाद शेष पृष्ठभूमि गतिविधि लगभग शून्य है, लेकिन शून्य नहीं।

क्या पुष्ट नहीं हुआ

• वास्तविक गेम में FPS में वृद्धि, input lag या frametime में कमी: मापा नहीं गया। सिंथेटिक CPU जाँचें GPU वाले गेम का अनुकरण नहीं करतीं और गेमिंग प्रभाव साबित नहीं करतीं।
• हर अलग बदलाव का अलग-अलग योगदान: बदलावों का पूरा समूह लागू किया गया था।
• निरपेक्ष मानों को भौतिक हार्डवेयर, अन्य बिल्ड और अन्य अनुकूलन प्रोफ़ाइलों पर लागू करना।
• लंबे समयखंडों में स्थिरता: प्रत्येक चरण 5 मिनट का था; Windows का पृष्ठभूमि कार्य उछालों में आता है, इसलिए «औसत दिन» नहीं मापा गया।

सीमाएँ

• माप वर्चुअल मशीन में किए गए। वर्चुअलाइज़ेशन अपना DPC/ISR योगदान जोड़ता है और होस्ट की शेड्यूलिंग छिपाता है; भौतिक हार्डवेयर पर निरपेक्ष मान अलग होंगे। समान परिस्थितियों में «पहले/बाद» की तुलना का अनुपात और दिशा बनी रहती है।
• ISR मेट्रिक को तालिकाओं से बाहर रखा गया है: वर्चुअल मशीन में PDH का ISR काउंटर, ETW के अनुसार इंटरप्ट हैंडलरों से लगभग 10 % अलग है और सटीक कुल से मेल नहीं खाता।
• श्रृंखला 2 के «पहले» समयखंड में Defender की सक्रिय स्कैनिंग थी, और समयखंडों के बीच होस्ट लोड अलग था (औसतन 44 % बनाम 24 %)। इसलिए मान विशिष्ट समयखंडों पर लागू होते हैं; प्रभाव की दिशा दो श्रृंखलाओं से पुष्ट हुई।
• श्रृंखला 1 में निष्क्रिय अवस्था का कुछ हिस्सा वर्चुअल मशीन के लगभग 26 सेकंड के बाहरी विराम से बाधित हुआ; फिर से शुरू होने के बाद रिकॉर्डिंग पूरी हुई और कोई घटना नहीं खोई।
• लोड जाँचों के दो दोहराव थे: यह वर्णनात्मक आँकड़े हैं, सांख्यिकीय महत्त्व का आकलन नहीं किया गया।
• निष्क्रिय अवस्था में लाभ का कुछ हिस्सा Microsoft Defender सुरक्षा घटकों को अक्षम करने से जुड़ा है। एंटीवायरस सुरक्षा के बिना सिस्टम एक सोच-समझकर किया गया समझौता है, बिना किसी लागत वाला अनुकूलन नहीं; सुरक्षा को उसकी कीमत समझकर ही अक्षम करें।
• मापन परत (ट्रेसिंग और काउंटर) स्वयं भी थोड़ा पृष्ठभूमि लोड पैदा करती है; यह दोनों स्थितियों में मौजूद है।

अध्ययन और इसमें इस्तेमाल किए गए उपकरण BoosterX के डेवलपर के हैं, इसलिए डेवलपर का परिणामों में प्रत्यक्ष हित है। कार्यविधि और लागू होने की सीमाएँ ऊपर बताई गई हैं, और निष्कर्षों को खुले डेटा तथा सूचीबद्ध सार्वजनिक स्रोतों से जाँचा जा सकता है।

व्यावहारिक निष्कर्ष

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

इससे क्या अपेक्षा नहीं करनी चाहिए: पूर्ण लोड के तहत प्रदर्शन में वृद्धि। यदि CPU पहले से ही उपयोगी कार्य से ~89 % क्षमता तक लोड है, तो पृष्ठभूमि गतिविधि अक्षम करने से शेष 11 % नहीं जुड़ेंगे — वर्चुअल मशीन में वे Windows के नहीं हैं। तुलना के समय सिस्टम किस काम में लगा है, उसी से दिखाई देने वाला प्रभाव तय होता है: रखरखाव के समयखंड में अंतर कई गुना होता है, शांत समयखंड में मध्यम।

सिफ़ारिश: अपने कंप्यूटर पर किसी भी बदलाव से पहले और बाद में पृष्ठभूमि गतिविधि का आकलन करें (Task Manager → «प्रदर्शन» और «प्रक्रियाएँ», Resource Monitor), दूसरों के प्रतिशतों पर भरोसा न करें। यदि लक्ष्य किसी खास गेम में FPS है, तो बदलाव से पहले और बाद में उसी को मापें।

स्थिति बहाल करना

दोनों श्रृंखलाएँ डिस्क की स्वतंत्र प्रतियों पर अलग-थलग वर्चुअल मशीनों में चलाई गईं; माप के बाद मशीनों को उनकी मूल स्थिति में लौटाया गया। लेख में पाठक से सेटिंग बदलने की अपेक्षा नहीं है, इसलिए उपयोगकर्ता के कंप्यूटर पर स्थिति बहाल करने की अलग कार्रवाई की आवश्यकता नहीं है।

सार्वजनिक प्राथमिक स्रोत

• Microsoft: Windows Performance Recorder — कार्यविधि में इस्तेमाल किया गया ETW ट्रेस रिकॉर्डिंग टूल; 2026-09-20 को जाँचा गया।
• Microsoft: About Event Tracing — ETW मॉडल और खोई हुई घटनाओं की जाँच; 2026-09-20 को जाँचा गया।
• Microsoft: Windows में Microsoft Defender Antivirus — Defender की प्रक्रियाएँ और सेवाएँ, जिनमें MsMpEng.exe (Task Manager में «Antimalware Service Executable») शामिल है; 2026-09-20 को जाँचा गया।
• हम Windows का अध्ययन कैसे करते हैं — प्रमाण के स्तर और मापन प्रोटोकॉल।
• Service Host और Windows 11 की पृष्ठभूमि प्रक्रियाएँ — Windows पृष्ठभूमि सेवाओं को प्रक्रियाओं में कैसे रखता है।
• Windows में वास्तव में कितनी मेमोरी मुक्त की जा सकती है — इसी प्रयोग के मेमोरी डेटा का विस्तृत विश्लेषण।
• डेस्कटॉप बनाम साइन-इन स्क्रीन — आगे का लेख: उपयोगकर्ता सत्र का शोर किन चीज़ों से बनता है।

बदलावों का इतिहास

• 2026-09-20: पहला प्रकाशन — निष्क्रिय अवस्था के माप की दो स्वतंत्र श्रृंखलाएँ, बूट के बाद के चरण, इन्वेंटरी और लोड जाँचें।
• 2026-09-20: श्रृंखलाओं के अनुसार परिणामों का श्रेय स्पष्ट किया गया (commit और उपयोग की गई भौतिक मेमोरी केवल श्रृंखला 2 के लिए; प्रक्रियाएँ −49…−56 %); हितों के टकराव संबंधी अस्वीकरण को मानक रूप दिया गया।