خمول هادئ: خلفية Windows قبل وبعد التحسين
على هذه الصفحة
الإجابة المختصرة
Section titled “الإجابة المختصرة”يؤدي تعطيل مكوّنات Windows الخلفية فعلاً إلى جعل الخمول أهدأ: في سلسلتين مستقلتين من القياسات انخفض عدد العمليات بنسبة 49–56 %، وانخفضت إشغال CPU في الخمول بنسبة 17–67 %، وانخفض حجم التزامات الذاكرة (commit) بنسبة 52 % في السلسلة الثانية. لكن تحت حمل CPU الكامل لم تزد الإنتاجية إلا بنسبة 0,2–0,5 %. «الخمول الهادئ» هو انخفاض مؤكَّد في العمل الخلفي والتنافس على الموارد، وليس زيادة في FPS: لم يُقَس الأثر النهائي في الألعاب في هذه الدراسة.
الحالة: أُعيد إنتاج اتجاه الأثر في سلسلتين مستقلتين على بناء واحد من Windows 11 في جهاز افتراضي. تختلف المقادير بين السلسلتين لأن العمل الخلفي في Windows يأتي على شكل دفعات: في نافذة تتضمن فحص Microsoft Defender يبلغ الفرق في إشغال CPU −67 %، وفي نافذة هادئة أصلاً — −17 %.
الادّعاء القابل للتحقق
Section titled “الادّعاء القابل للتحقق”تحققنا من أربعة ادّعاءات:
- تعطيل المكوّنات الخلفية يخفض نشاط النظام في الخمول بشكل ملحوظ.
- يخفض النشاط بشكل ملحوظ في الدقائق الأولى بعد الإقلاع.
- يقلّل استهلاك الذاكرة بشكل ملحوظ.
- يعطي زيادة قابلة للقياس في الأداء تحت حمل CPU الكامل.
نطاق الدراسة
Section titled “نطاق الدراسة”- Windows 11 Pro، build 26300.9457 (26H2)؛
- جهاز افتراضي: 4 vCPU، 8 غيغابايت RAM، محاكاة VMware؛
- حالتان لتثبيت واحد: الأصلية («قبل») وبعد تطبيق ملف تعريف التحسين من BoosterX (البناء الساري في تواريخ القياسات)؛
- سلسلتان مستقلتان من القياسات: 2026-09-18 و2026-09-19؛ قُورنت الحالتان على نسخ مستقلة من القرص حتى لا تؤثر القياسات إحداها في الأخرى؛
- المراحل: 5 دقائق بعد الإقلاع، 5 دقائق استقرار، 5 دقائق خمول؛
- أحمال اصطناعية قصيرة: 1 و4 و8 خيوط، وحمل على الذاكرة، وحمل مُوقَّت، وخلائط أولويات.
لم تشمل القياسات ألعاباً حقيقية، ولا حملاً على GPU، ولا عتاداً فيزيائياً، ولا نوافذ طويلة (ساعات وأيام).
المنهجية
Section titled “المنهجية”تتوافق البروتوكول مع «كيف نبحث Windows»:
- سُجّلت كل مرحلة عبر تتبّع ETW (Windows Performance Recorder، ملفات تعريف خفيفة لـ CPU والقرص والملفات والشبكة) وعدّادات الأداء بفاصل 5 ثوانٍ (النظام) و15 ثانية (بحسب العمليات)؛
- بدأت مرحلة «بعد الإقلاع» بإعادة تشغيل مضبوطة وانطلقت عند زمن تشغيل يقارب دقيقة واحدة؛
- فُحص في كل تتبّع عدد الأحداث المفقودة — وهو صفر في جميع النوافذ المذكورة؛
- أُجري حساب المتوسط فقط على فواصل الخمس ثوانٍ الكاملة داخل حدود المرحلة (59 فاصلاً لكل مرحلة)؛
- في السلسلة 2 استُبعد التشغيل الأول لـ «قبل» بسبب دخول الجهاز الافتراضي في وضع السكون؛ واستُخدمت الإعادة؛
- نُفّذت اختبارات الحمل مرتين، والمذكور هو الوسيطات؛ وإشغال CPU مُعيَّر على أربع vCPU.
«قبل» و«بعد» حالتان لتثبيت Windows واحد: «بعد» ناتجة عن تطبيق ملف تعريف التحسين، و«قبل» هي الحالة الأصلية. تغيّرت مجموعة الإعدادات كاملة، لذلك لم يُقيَّم Contribution تعطيل واحد بعينه بشكل معزول.
النتائج
Section titled “النتائج”الخمول
Section titled “الخمول”السلسلة 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 % |
| الذاكرة المتاحة، ميغابايت | 5 490 | 6 518 | +1 028 |
| القراءة من القرص، كيلوبايت/ث | 22,6 | 24,4 | +8 % |
| الكتابة على القرص، كيلوبايت/ث | 311,3 | 262,1 | −16 % |
| الشبكة (استقبال)، كيلوبايت/ث | 132,6 | 2,2 | −98 % |
| الشبكة (إرسال)، كيلوبايت/ث | 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 % |
| الذاكرة المتاحة، ميغابايت | 5 174 | 6 653 | +1 479 |
| الذاكرة الفيزيائية المشغولة، ميغابايت | 3 017 | 1 538 | −49 % |
| التزامات الذاكرة (commit)، ميغابايت | 2 617 | 1 249 | −52 % |
| Nonpaged pool، ميغابايت | 298,2 | 212,9 | −29 % |
| Paged pool، ميغابايت | 258,5 | 86,0 | −67 % |
| DPC، % CPU | 0,89 | 0,19 | −78 % |
| القراءة من القرص، ميغابايت/ث | 7,42 | 0,01 | −99,9 % |
| الكتابة على القرص، ميغابايت/ث | 4,57 | 0,23 | −95,0 % |
لم تكن هناك شبكة تقريباً في خمول السلسلة 2 في كلتا الحالتين (عشرات البايتات في الثانية)، لذلك لا تُذكر صفوف الشبكة لها. الفرق بين السلسلتين ليس تناقضاً، بل خاصية للخلفية نفسها: عندما تنفّذ Windows صيانة، يوفّر تعطيل المكوّنات الخلفية أكثر؛ وعندما تكون النافذة هادئة أصلاً — أقل.
الدقائق الأولى بعد الإقلاع
Section titled “الدقائق الأولى بعد الإقلاع”| المقياس | السلسلة 1 (قبل → بعد) | السلسلة 2 (قبل → بعد) |
|---|---|---|
| إشغال CPU، % | 3,42 → 2,59 | 14,62 → 11,88 |
| تبديلات السياق، /ث | 1 114 → 600 | 1 257 → 393 |
| العمليات | 132 → 74 | 139 → 64 |
| الخيوط | — | 1 719 → 746 |
| الذاكرة الفيزيائية المشغولة، ميغابايت | — | 2 821 → 1 581 |
| الذاكرة المتاحة، ميغابايت | — | 5 370 → 6 610 |
| القراءة من القرص، كيلوبايت/ث | — | 826 → 433 |
| الكتابة على القرص، كيلوبايت/ث | 634 → 418 | 709 → 298 |
| الشبكة (استقبال)، كيلوبايت/ث | — | 1,15 → ~0 |
تعني الشرطة أن المقياس لم يُسجَّل لهذه المرحلة في تلك السلسلة.
التركيب والذاكرة
Section titled “التركيب والذاكرة”لقطة جرد في الخمول (السلسلة 1):
| قبل | بعد | |
|---|---|---|
| العمليات | 136 | 70 |
| الخيوط | 1 679 | 842 |
| إجمالي working set، ميغابايت | 3 841 | 1 868 |
| إجمالي private bytes، ميغابايت | 1 524 | 660 |
أكبر مستهلكي الذاكرة قبل التحسين: عملية مكافحة الفيروسات MsMpEng.exe (257 ميغابايت)، explorer.exe (213 ميغابايت)، StartMenuExperienceHost (144 ميغابايت)، msedge.exe (133 ميغابايت)، SearchHost.exe (122 ميغابايت). بعد التحسين تصدّرت القائمة explorer.exe (170 ميغابايت)، msedgewebview2 (119 ميغابايت)، SearchHost.exe (115 ميغابايت) وStartMenuExperienceHost (106 ميغابايت).
زادت الذاكرة المتاحة بمقدار 1,0–1,5 غيغابايت، وانخفض حجم الالتزامات (commit) بنسبة 52 %. وما يمكن فعلاً «تحريره» من ذلك، ولماذا مجموع working set للعمليات ليس هو نفسه الذاكرة الحرة، مُفصَّل في «كم من الذاكرة يمكن فعلاً تحريره في Windows».
تحت الحمل الكامل
Section titled “تحت الحمل الكامل”اختبارات اصطناعية قصيرة (السلسلة 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 مِث) | +5,4 % | 64,3 / 67,7 % |
| أولويات مختلطة | +8,5 % | 21,2 / 22,5 % |
| أولوية خلفية | +77,1 % | 38,8 / 65,2 % |
تحت حمل كامل بأربعة خيوط حصلت العملية النافعة على نحو 89 % من سعة أربع vCPU قبل التحسين وبعده. ولا يمكن إعلان الـ ~11 % المتبقية في الجهاز الافتراضي «ضجيجاً من Windows» قابلاً للإزالة: فجدولة الـ hypervisor لا تظهر من تتبّع الضيف. وُزّعت خيوط العمل بالتساوي (تشتّت حجم العمل بينها — 0,994–0,997)، ولم يُلاحظ أي تجويع، وقائمة انتظار CPU في الخمول بعد التحسين شبه فارغة.
إلى أين تذهب الخلفية
Section titled “إلى أين تذهب الخلفية”مصادر النشاط الخلفي المقيسة في حالة «قبل»:
- فحص مكافحة الفيروسات — المصدر الرئيسي في نافذة السلسلة 2: استهلكت العملية
MsMpEng.exe212 ثانية CPU خلال نافذة خمول مدتها خمس دقائق؛ - في الحالة الأصلية كانت تعمل خدمة البحث وخدمة SysMain والقياس عن بُعد ومدير الطباعة ومكوّنات أخرى — ويضع ملف تعريف التحسين نحو 50 خدمة خلفية و58 مهمة مجدولة في حالة التعطيل؛
- بعد الإقلاع يرافق النشاطَ منسّق تحديثات Windows.
لا يزيل تعطيل المكوّنات الخلفية الخلفية بالكامل: في الحالة المحسَّنة استمرّ العمل على تقييم توافق التطبيقات (نحو 3,7 مِث CPU في الثانية في نافذة الصيانة)، وبلغ مجموع الخلفية المتبقية في الخمول المستقر 4,8 مِث CPU في الثانية — نحو 0,12 % من سعة أربع vCPU (مقيس من التتبّع).
ما تم تأكيده
Section titled “ما تم تأكيده”- أُعيد إنتاجه (سلسلتان مستقلتان): عدد العمليات −49…−56 %، والخيوط −49…−57 %، والذاكرة المتاحة +1,0–1,5 غيغابايت.
- مقيس (السلسلة 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 نفسها، بما في ذلك فحص مكافحة الفيروسات.
- لوحظ: المصادر الرئيسية للخلفية هي فحص مكافحة الفيروسات والصيانة ومهام التوافق؛ وبعد التحسين تقترب الخلفية المتبقية من الصفر لكنها ليست صفراً.
ما لم يتم تأكيده
Section titled “ما لم يتم تأكيده”- زيادة FPS أو خفض input lag أو frametime في ألعاب حقيقية: لم يُقَس. فالاختبارات الاصطناعية على CPU لا تحاكي لعبة مع GPU ولا تثبت أثراً في الألعاب.
- Contribution كل تعطيل بعينه بشكل معزول: طُبّقت مجموعة تغييرات كاملة.
- نقل المقادير المطلقة إلى عتاد فيزيائي وبنى أخرى وملفات تعريف تحسين أخرى.
- الثبات على نوافذ طويلة: كل مرحلة 5 دقائق؛ والعمل الخلفي في Windows يأتي على شكل دفعات، لذلك لم يُقَس «يوم متوسط».
القيود
Section titled “القيود”- أُجريت القياسات في جهاز افتراضي. تضيف المحاكاة نصيبها الخاص من DPC/ISR وتخفي جدولة المضيف؛ وعلى العتاد الفيزيائي ستكون القيم المطلقة مختلفة. أما النسب واتجاه المقارنة «قبل/بعد» في الظروف نفسها فتبقى.
- استُبعد مقياس ISR من الجداول: في الجهاز الافتراضي يتباعد عدّاد ISR عبر PDH عن معالِجات المقاطعات عبر ETW بنحو 10 % ولا يتطابق في مجموع دقيق.
- احتوت نافذة «قبل» في السلسلة 2 على فحص Defender نشط، واختلف حمل المضيف بين النوافذ (بمتوسط 44 % مقابل 24 %). لذلك ترتبط المقادير بنوافذ محددة؛ وقد أُكِّد الاتجاه بسلسلتين.
- في السلسلة 1 قُوطعت جزء من مرحلة الخمول بفاصل خارجي للجهاز الافتراضي لنحو 26 ثانية؛ وانتهى الالتقاط بعد الاستئناف، ولا توجد أحداث مفقودة.
- اختبارات الحمل — إعادتان: هذه إحصاءات وصفية، ولم تُقيَّم الدلالة الإحصائية.
- يرتبط جزء من المكسب في الخمول بتعطيل مكوّنات حماية Microsoft Defender. فالنظام بلا حماية من الفيروسات حل وسط واعٍ، وليس تحسيناً بلا تكاليف؛ ويجب تعطيل الحماية مع إدراك الثمن.
- طبقة القياس نفسها (التتبّع والعدّادات) تخلق حمل خلفي صغيراً؛ وهو موجود في كلتا الحالتين.
الدراسة والأدوات المستخدمة ملك لمطوّر BoosterX، لذلك للمطوّر مصلحة مباشرة في النتائج. المنهجية وحدود قابلية التطبيق موصوفة أعلاه، ويمكن التحقق من الاستنتاجات عبر البيانات المفتوحة والمصادر العامة المذكورة.
الخلاصة العملية
Section titled “الخلاصة العملية”خفض الضجيج الخلفي أثر حقيقي أُعيد إنتاجه مرتين: نصف عدد العمليات والخيوط، ونصف التزامات الذاكرة، ونشاط قرص وشبكة في الخمول أقل بمرتبة قدر. وهذا مفيد بحد ذاته — لاستجابة النظام والمهام الخلفية والحرارة وضجيج المراوح وعمر البطارية — ولا يحتاج إلى وعود بـ FPS.
وما لا ينبغي انتظاره من ذلك: زيادة الأداء تحت الحمل الكامل. فإذا كان CPU مشغولاً أصلاً بعمل نافع بنحو ~89 % من السعة، فلن يضيف تعطيل النشاط الخلفي الـ 11 % المتبقية — فهي في الجهاز الافتراضي لا تنتمي إلى Windows. وكلما زاد انشغال النظام لحظة المقارنة، زاد الأثر المرئي: في نافذة الصيانة يكون الفرق مضاعفاً، وفي نافذة هادئة — معتدلاً.
التوصية: قيّم الخلفية قبل أي تغييرات وبعدها على حاسوبك (Dispenser المهام → «الأداء» و«العمليات»، ومراقب الموارد)، ولا تستند إلى نسب الآخرين. وإذا كان الهدف هو FPS في لعبة بعينها، فقِسْه هو نفسه قبل التغيير وبعده.
استعادة الحالة
Section titled “استعادة الحالة”أُجريت السلسلتان في أجهزة افتراضية معزولة على نسخ مستقلة من القرص؛ وبعد القياسات أُعيدت الأجهزة إلى حالاتها الأصلية. ولا تتطلب المقالة من القارئ تغيير أي إعدادات، لذلك لا حاجة إلى إجراء استعادة منفصل على حاسوب المستخدم.
المصادر الأولية العامة
Section titled “المصادر الأولية العامة”- Microsoft: Windows Performance Recorder — أداة تسجيل تتبّعات ETW المستخدمة في المنهجية؛ تم التحقق في 2026-09-20.
- Microsoft: About Event Tracing — نموذج ETW والتحقق من الأحداث المفقودة؛ تم التحقق في 2026-09-20.
- Microsoft: Microsoft Defender Antivirus في Windows — عمليات وخدمات Defender، بما في ذلك
MsMpEng.exe(«Antimalware Service Executable» في Task Manager)؛ تم التحقق في 2026-09-20. - كيف نبحث Windows — مستويات الأدلة وبروتوكول القياسات.
- Service Host والمكوّنات الخلفية في Windows 11 — كيف توزّع Windows الخدمات الخلفية على العمليات.
- كم من الذاكرة يمكن فعلاً تحريره في Windows — تحليل مفصّل للذاكرة من التجربة نفسها.
- سطح المكتب مقابل شاشة الدخول — تكملة: مما يتكوّن ضجيج جلسة المستخدم.
سجل التغييرات
Section titled “سجل التغييرات”- 2026-09-20: النشر الأول — سلسلتان مستقلتان من قياسات الخمول، ومراحل ما بعد الإقلاع، والجرد، واختبارات الحمل.
- 2026-09-20: توضيح إسناد النتائج إلى السلسلتين (commit والذاكرة الفيزيائية المشغولة — السلسلة 2 فقط؛ العمليات −49…−56 %)؛ وإحالة إخلاء المسؤولية بشأن تضارب المصالح إلى الصيغة المعيارية.