الخمول الهادئ: نشاط 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 غيغابايت RAM، مع المحاكاة الافتراضية من VMware؛
• حالتان للتثبيت نفسه: الحالة الأصلية («قبل») وبعد تطبيق ملف تحسين BoosterX (الإصدار المتاح في تاريخ القياسات)؛
• سلسلتان مستقلتان من القياسات: 2026-09-18 و2026-09-19؛ قورنت الحالتان على نسختين مستقلتين من القرص كي لا تؤثر القياسات إحداها في الأخرى؛
• المراحل: 5 دقيقة بعد الإقلاع، و5 دقيقة للاستقرار، و5 دقيقة من الخمول؛
• اختبارات اصطناعية قصيرة: 1 و4 و8 خيوط، وحمل على الذاكرة، وحمل متقطع، ومزيج من الأولويات.

لم تشمل القياسات ألعابًا فعلية أو حمل GPU أو أجهزة فعلية أو فترات طويلة (ساعات وأيام).

نُشرت سلسلة منفصلة على جهاز فعلي بمعالج Ryzen 7 7800X3D، شملت أربع مراحل وقياسات للألعاب، في مقالة «BoosterX: خلفية Windows وFPS في CS2». ولا تُدمج نتائجها مع هذه السلسلة التي أُجريت على أجهزة افتراضية.

المنهجية

يتوافق البروتوكول مع «كيف ندرس 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 %
الذاكرة المتاحة، ميغابايت	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 أعمال الصيانة، يوفر تعطيل مكونات الخلفية قدرًا أكبر؛ وعندما تكون الفترة هادئة أصلًا، يكون التوفير أقل.

الدقائق الأولى بعد الإقلاع

المقياس	السلسلة 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

تعني الشرطة أن المقياس لم يُسجّل لهذه المرحلة في تلك السلسلة.

التركيب والذاكرة

لقطة جرد النظام أثناء الخمول (السلسلة 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 %. يشرح «ما مقدار الذاكرة التي يمكن تحريرها فعليًا في Windows» ما الذي يمكن «تحريره» فعلًا من ذلك، ولماذا لا يساوي مجموع working set للعمليات الذاكرة الحرة.

تحت حمل كامل

اختبارات اصطناعية قصيرة (السلسلة 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» قابل للإزالة: لا يظهر تخطيط عمل برنامج المحاكاة الافتراضية في تتبّع النظام الضيف. وُزعت خيوط العمل بالتساوي (تفاوت حجم العمل بينها — 0,994–0,997)، ولم يُلاحظ تجويع للخيوط، وكان طابور CPU أثناء الخمول شبه فارغ بعد التحسين.

مصادر النشاط في الخلفية

مصادر نشاط الخلفية التي قِيست في حالة «قبل»:

• فحص مكافحة الفيروسات — المصدر الرئيسي في فترة السلسلة 2: استهلكت العملية MsMpEng.exe مقدار 212 ثانية CPU خلال فترة خمول مدتها خمس دقائق؛
• كانت خدمة البحث وخدمة SysMain والقياس عن بُعد ومدير الطباعة ومكونات أخرى تعمل في الحالة الأصلية — وينقل ملف التحسين نحو 50 خدمة خلفية و58 مهمة مجدولة إلى حالة التعطيل؛
• يرافق نشاط ما بعد الإقلاع منسّق تحديثات Windows.

لا يؤدي تعطيل مكونات الخلفية إلى إزالتها بالكامل: ففي الحالة المحسّنة، استمر تقييم توافق التطبيقات في العمل (نحو 3,7 مللي ثانية CPU في الثانية خلال فترة الصيانة)، وبلغ إجمالي النشاط المتبقي في الخلفية أثناء الخمول المستقر 4,8 مللي ثانية CPU في الثانية — أي نحو 0,12 % من سعة أربعة vCPU (وفقًا للقياس بالتتبّع).

ما تم تأكيده

• تكرر في القياس (سلسلتان مستقلتان): انخفض عدد العمليات بنسبة −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 نفسه في الخلفية، بما في ذلك فحص مكافحة الفيروسات.
• لوحظ: كانت المصادر الرئيسية للنشاط في الخلفية هي فحص مكافحة الفيروسات والصيانة ومهام التوافق؛ وبعد التحسين، اقترب النشاط المتبقي في الخلفية من الصفر، لكنه لم يبلغه.

ما لم يتم تأكيده

• زيادة FPS أو انخفاض input lag أو frametime في الألعاب الفعلية: لم تُقَس. لا تحاكي اختبارات CPU الاصطناعية لعبة تستخدم GPU، ولا تثبت أثرًا على الألعاب.
• الأثر المنفرد لكل تعطيل على حدة: طُبّقت مجموعة تغييرات كاملة.
• تعميم القيم المطلقة على الأجهزة الفعلية أو الإصدارات الأخرى أو ملفات التحسين الأخرى.
• الاستقرار على فترات طويلة: استغرقت كل مرحلة 5 دقيقة؛ ويأتي نشاط Windows في الخلفية على شكل دفعات، لذلك لم يُقَس «متوسط يوم».

القيود

• أُجريت القياسات داخل جهاز افتراضي. وتضيف المحاكاة الافتراضية قدرًا خاصًا بها من DPC/ISR، كما تخفي تخطيط عمل المضيف؛ لذلك ستكون القيم المطلقة مختلفة على الأجهزة الفعلية. أما النسب واتجاه المقارنة «قبل/بعد» فيبقيان كما هما في الظروف المتطابقة.
• استُبعد مقياس ISR من الجداول: ففي الجهاز الافتراضي، يختلف عداد ISR عبر PDH عن معالجات المقاطعات عبر 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: Microsoft Defender Antivirus في Windows — عمليات Defender وخدماته، بما فيها MsMpEng.exe («Antimalware Service Executable» في Task Manager)؛ تم التحقق في 2026-09-20.
• كيف ندرس Windows — مستويات الأدلة وبروتوكول القياس.
• Service Host ومكونات الخلفية في Windows 11 — كيفية استضافة Windows للخدمات الخلفية ضمن العمليات.
• ما مقدار الذاكرة التي يمكن تحريرها فعليًا في Windows — تحليل مفصل للذاكرة من التجربة نفسها.
• سطح المكتب مقابل شاشة تسجيل الدخول — متابعة: ممّ يتكون ضجيج جلسة المستخدم.

سجل التغييرات

• 2026-09-20: النشر الأول — سلسلتان مستقلتان لقياس الخمول، ومراحل ما بعد الإقلاع، والجرد، واختبارات الحمل.
• 2026-09-20: توضيح إسناد النتائج إلى السلاسل (commit والذاكرة الفعلية المستخدمة — السلسلة 2 فقط؛ العمليات −49…−56 %)؛ وتوحيد إخلاء المسؤولية بشأن تضارب المصالح مع الصياغة المعتمدة.