كم من الذاكرة يمكن فعليًا تحريره في Windows
على هذه الصفحة
الإجابة المختصرة
Section titled “الإجابة المختصرة”ما يمكن تحريره فعليًا أقل مما تعد به «أدوات تحسين الذاكرة». في هذه التجربة، أدى تعطيل المكونات الخلفية إلى تحرير 1,0–1,5 غيغابايت من الذاكرة المتاحة وتقليص حجم الالتزامات (commit) بنسبة 52 % في السلسلة 2. لكن الطرق السريعة الشائعة لا تعمل: إنهاء عمليات الواجهة — يعيد Windows تشغيلها بنفسه خلال نحو 20 ثانية؛ تنظيف working set — تبقى الصفحات المُفرَّغة في RAM كذاكرة مؤقتة؛ معاملات Registry الخاصة بمدير الذاكرة — لا فائدة مؤكدة لها. أعطى التعطيل الموجَّه فوق نظام مُحسَّن مسبقًا +22–30 ميغابايت صافية. الذاكرة في قائمة standby هي ذاكرة مؤقتة محسوبة أصلًا ضمن «المتاحة».
الحالة: الأرقام النهائية مستخلصة في جهاز افتراضي بذاكرة RAM سعة 8 غيغابايت على Windows 11 (26H2, build 26300.9457). الاتجاهات مؤكدة بتوثيق Microsoft وتجاربنا المضبوطة؛ القيم المطلقة على تهيئة أخرى ستكون مختلفة.
الادعاءات القابلة للتحقق
Section titled “الادعاءات القابلة للتحقق”تحققنا من أربعة ادعاءات:
- إنهاء العمليات الخلفية «غير الضرورية» يحرر الذاكرة.
- تنظيف working set أو قائمة standby (آلية «أدوات تحسين RAM») يحرر الذاكرة.
- معاملات Registry الخاصة بمدير الذاكرة تحرر الذاكرة بشكل ملحوظ.
- تعطيل المكونات الخلفية يحرر حجمًا كبيرًا من الذاكرة.
نطاق البحث
Section titled “نطاق البحث”- Windows 11 Pro, build 26300.9457 (26H2)؛ جهاز افتراضي، 8 غيغابايت RAM؛
- حالتان لتثبيت واحد: الأصلية («قبل») وبعد تطبيق ملف تعريف التحسين BoosterX — أُجري القياس في سلسلتين مستقلتين (البروتوكول المفصل وبقية المقاييس — في «الخمول الهادئ: خلفية Windows قبل التحسين وبعده»)؛
- فوق حالة «بعد» — حزمة تعطيلات موجَّهة للمصادر الخلفية (مسجّلات ETW التشخيصية التلقائية، وخدمات الإشعارات، والنسخ الظلي، ومنسّق التحديثات)؛
- المقاييس: الذاكرة المتاحة والمشغولة، وحجم الالتزامات (commit)، وnonpaged/paged pool، وworking set وprivate bytes حسب العمليات، وأخطاء الصفحات (hard faults).
لم نشمل: العتاد الفيزيائي، والأنظمة بذاكرة RAM بسعة أخرى، وتجارب تعطيل pagefile، والأدوات الخارجية «لتحسين الذاكرة».
المنهجية
Section titled “المنهجية”- أُخذ جرد الذاكرة في خمول مستقر: عدّادات النظام (المتاحة، المشغولة، commit، pools) وقائمة العمليات مع working set وprivate bytes.
- تجربة مضبوطة «إنهاء عمليات الواجهة»: أُوقفت عمليتا واجهة (
SearchHost.exeوStartMenuExperienceHost)، وفُحصت الحالة بعد 20 و40 ثانية؛ وسُجّل commit قبل وبعد. - طُبّقت حزمة التعطيلات الموجَّهة على حالة «بعد»، ثم أُجري إعادة تشغيل ومقارنة مع أربع عمليات تشغيل ضابطة للحالة نفسها دون الحزمة؛ وفحصت اختبارات التشغيل غياب أي تراجع في الأداء.
- طبقة القياس (التتبع، والعدّادات، وسكربتات الجمع) تشغل هي نفسها ذاكرة — تصل إلى مئة ميغابايت وأكثر من working set في بعض القياسات؛ وهذا مذكور في القيود.
النتائج
Section titled “النتائج”كم تشغل الخلفية
Section titled “كم تشغل الخلفية”لقطة الجرد في الخمول (السلسلة 1):
| قبل | بعد | التغيير | |
|---|---|---|---|
| إجمالي working set، ميغابايت | 3 841 | 1 868 | −51 % |
| إجمالي private bytes، ميغابايت | 1 524 | 660 | −57 % |
| الذاكرة المتاحة، ميغابايت | 5 490 | 6 518 | +1 028 |
السلسلة 2: الذاكرة المشغولة 3 017 → 1 538 ميغابايت، والمتاحة 5 174 → 6 653 ميغابايت، وحجم الالتزامات 2 617 → 1 249 ميغابايت. الاتجاه متطابق في السلسلتين: المكونات الخلفية تحتفظ بنحو نصف الذاكرة المشغولة في هذا الملف التعريفي.
بنية الذاكرة المشغولة
Section titled “بنية الذاكرة المشغولة”في حالة «بعد» توزعت الذاكرة هكذا (إجمالي working set، السلسلة 1):
- الواجهة (مستكشف الملفات، DWM، البحث في قائمة «ابدأ»، مضيف الجلسة) — نحو 640 ميغابايت؛
- الخدمات الخلفية — نحو 640 ميغابايت (57 خدمة في 39 عملية مضيفة)؛
- مكوّن البحث على الويب — نحو 320 ميغابايت؛
- pools النواة — نحو 167 ميغابايت، منها نحو 76 ميغابايت تشغلها pools Registry.
working set للعملية لا يساوي الذاكرة القابلة للتحرير: فهو يشمل صفحات مشتركة (كود مكتبات النظام، والبيانات المشتركة) تُحتسب في كل عملية في الوقت نفسه. في حالة «بعد» للسلسلة 1 كان مجموع working set لـ 75 عملية 1 868 ميغابايت، ومجموع private bytes — 660 ميغابايت؛ وفي عمليات التشغيل الضابطة لتجربة التعطيلات الموجَّهة كان إجمالي working set 2 036 ميغابايت. أكبر عمليات الواجهة (السلسلة 2):
| العملية | Working set، ميغابايت | Private، ميغابايت |
|---|---|---|
SearchHost.exe (البحث) |
187 | 80 |
explorer.exe (مستكشف الملفات) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
في حالة «بعد» كانت قائمة standby 711 ميغابايت. هذه ليست ذاكرة مفقودة، بل ذاكرة مؤقتة: standby محسوبة أصلًا ضمن «المتاحة»، ويعيد Windows استخدام هذه الصفحات فورًا عندما يطلب تطبيق ما ذاكرة.
التجربة: إنهاء عمليات الواجهة
Section titled “التجربة: إنهاء عمليات الواجهة”بعد إيقاف SearchHost.exe وStartMenuExperienceHost (السلسلة 2):
- أعادت العمليتان تشغيل نفسيهما تلقائيًا خلال نحو 20 ثانية بمعرّفات جديدة؛ وبعد 40 ثانية كانتا ما تزالان تعملان؛
- لم ينخفض حجم الالتزامات، بل ارتفع 12,6 ميغابايت (من 1 386,9 إلى 1 399,5 ميغابايت) — إعادة تشغيل عمليات الواجهة تنشئ هي نفسها عملًا جديدًا؛
- الارتفاع القصير في الذاكرة «المتاحة» بمقدار 93 ميغابايت ليس توفيرًا: العمليات المستهدفة عادت، وcommit ازداد.
إنهاء مستكشف الملفات في قياس منفصل (السلسلة 1) لم يعطِ أيضًا نموًا مستقرًا للذاكرة الحرة: في هذه النافذة انخفضت الذاكرة الحرة حتى 97 ميغابايت مع نمو standby بمقدار 13 ميغابايت — تبقى الصفحات المُفرَّغة في النظام كذاكرة مؤقتة، وتواصل الواجهة والعمليات المرتبطة عملها.
خلاصة التجربة: الإنهاء القسري لعمليات النظام لا يحرر الذاكرة. يعيد Windows تشغيل مكونات الواجهة تلقائيًا، وبدلًا من التوفير تحصل على حمل إضافي.
تنظيف working set وقائمة standby
Section titled “تنظيف working set وقائمة standby”الآلية موثقة من Microsoft. إفراغ الصفحات من working set (مثلًا بالدالة EmptyWorkingSet أو SetProcessWorkingSetSize بحجم «فارغ» — وهي بالضبط ما تستخدمه «أدوات تحسين RAM») ينقل الصفحات إلى حالة انتقالية: تبقى مخزنة مؤقتًا في RAM حتى تُحتاج مجددًا أو يُعاد استخدامها. والوصول التالي للعملية إلى مثل هذه الصفحة هو خطأ صفحة ناعم وعودة إلى working set.
لذلك يغيّر تنظيف working set رقم «حر» في العدّادات، لكنه لا ينشئ ذاكرة متاحة فيزيائيًا: الصفحات لا تختفي إلى أي مكان، ويصبح الوصول إليها مجددًا أكثر كلفة. وتنظيف قائمة standby بلا معنى للسبب نفسه: standby ذاكرة متاحة للنظام أصلًا. في قياساتنا لم يكن هناك pressure على الذاكرة في كلتا الحالتين (بقيت hard faults منخفضة)، لذلك لم يحسّن الإفراغ الإضافي شيئًا.
معيارنا المستخلص من هذه التجربة: يجب تقييم نتيجة «تحرير الذاكرة» عبر commit، وأخطاء الصفحات، والزمن المستغرق عند إعادة استخدام الذاكرة، لا عبر النمو القصير لسطر «حر».
إيقافات محددة: مكسب صادق
Section titled “إيقافات محددة: مكسب صادق”فوق حالة «بعد» قمنا بتعطيل تسعة مسجلات تلقائية تشخيصية ETW وأربع خدمات خلفية (الإشعارات، النسخ الظلي، منسق التحديثات) وقارنّا النتيجة بأربع عمليات إقلاع مرجعية:
| المقياس | عمليات الإقلاع المرجعية | مع الحزمة | الفرق |
|---|---|---|---|
| الذاكرة الحرة، م.ب | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool، م.ب | 69,8–71,8 | 58,7 | −11…−13 |
| إجمالي working set، م.ب | 2 036 | 1 959 | −77 |
| أداء الاختبارات | دون تغيير | دون تغيير | — |
المسجلات التلقائية وحدها أعطت −13,2 م.ب من nonpaged pool (قيس بشكل منفصل). مهم: مجموع working set للمكونات المعطلة وفق الجرد كان نحو 78 م.ب، أما المكسب الفعلي في الذاكرة الحرة فهو +22–30 م.ب. ينشأ الفرق لأن جزءًا مما «عُطّل» لم يكن يعمل أصلًا. وهذا هو الحد الصادق للإيقافات المحددة دون إزالة مكونات النظام؛ وبشكل جانبي خفّضت الحزمة نفسها النشاط الخلفي في الخمول بمقدار 24 % إضافية.
معاملات السجل الخاصة بمدير الذاكرة (أحجام المجمعات، والذاكرة المؤقتة للنظام وما شابه) لم تُؤخذ في هذا الاختبار حتى كمصدر للمكسب: قراءتها وفائدتها العملية محللة في «Memory Manager وذاكرة النظام المؤقتة» — لا فائدة مؤكدة لها في تحرير RAM.
ما تم تأكيده
Section titled “ما تم تأكيده”- أُعيد إنتاجه (سلسلتان): تعطيل المكونات الخلفية يحرر 1,0–1,5 غ.ب من الذاكرة المتاحة؛ انخفض إجمالي working set بنسبة 51 % (السلسلة 1)، والذاكرة المشغولة بنسبة 49 % وحجم الالتزامات (commit) بنسبة 52 % (السلسلة 2).
- قيس: إعادة التشغيل التلقائي لعمليات الواجهة الموقوفة خلال 20 ثانية؛ ولا ينخفض commit عند ذلك (بل ارتفع في اختبارنا بمقدار 12,6 م.ب).
- قيس: إنهاء File Explorer لا يعطي نموًا مستدامًا في الذاكرة الحرة؛ فالصفحات المُفرغة تبقى في standby.
- موثّق: إفراغ الصفحات من working set ينقلها إلى حالة انتقالية مخزنة مؤقتًا في RAM؛ وتُحتسب ذاكرة standby ضمن المتاحة.
- قيس: الإيقافات المحددة فوق نظام مُحسَّن تعطي +22–30 م.ب من الذاكرة الحرة مع أداء دون تغيير؛ ومجموع working set لما عُطّل لا يساوي مكسب الذاكرة الحرة.
ما لم يتم تأكيده
Section titled “ما لم يتم تأكيده”- لم تُختبر «محسّنات RAM» الخارجية مباشرة: فقد فُحصت الآلية (تنظيف working set) التي تُبنى عليها.
- لم يُقس تعطيل pagefile؛ والمعروف فقط أن pagefile ضروري لـ crash dump وحد الالتزامات في الذاكرة.
- نقل القيم إلى أجهزة بحجم RAM مختلف وبنى أخرى وعتاد فعلي.
- استدامة التوفير على نوافذ زمنية طويلة: أُجريت القياسات في خمول مستقر.
القيود
Section titled “القيود”- جهاز افتراضي بذاكرة 8 غ.ب: الأرقام المطلقة مرتبطة بهذه التهيئة؛ والنمط ذو الحجم الأكبر من المكونات الخلفية سيحرر أكثر، والنظام «الهادئ» أقل.
- مجموع working set حسب العمليات يبالغ في الأثر الفريد بسبب الصفحات المشتركة؛ ولهذا نورد private bytes إلى جانبه.
- طبقة القياس نفسها كانت تشغل ذاكرة ملحوظة (حتى مئات الم.ب من working set في بعض القياسات) — فأرقام الحالة تتضمن وجود القياس.
- لم يكن هناك ضغط على الذاكرة في الاختبار (hard faults منخفضة)، لذلك لم نتحقق مما إذا كان التوفير يقلل الـ thrashing في ظروف نقص RAM.
- جزء من التحرير مرتبط بتعطيل مكونات حماية Microsoft Defender — وهذا مقايضة مع الأمان، وليست ذاكرة مجانية.
الدراسة والأدوات المستخدمة ملك لمطوّر BoosterX، وBoosterX مُحسّن Windows، لذا فإن قياس أثر التحسين مصلحة مباشرة له. المنهجية وحدود قابلية التطبيق موصوفة أعلاه، ويمكن التحقق من الاستنتاجات عبر البيانات المفتوحة والمصادر العامة المذكورة. وقد نُشرت النتائج السلبية بشأن الطرق الشائعة «لتحرير الذاكرة» جنبًا إلى جنب مع الإيجابية.
الخلاصة العملية
Section titled “الخلاصة العملية”ما يحرر الذاكرة فعليًا، وفق هذا الاختبار:
- إغلاق التطبيقات غير المستخدمة — تُحرر private bytes الخاصة بها بالكامل؛
- تعطيل المكونات الخلفية غير الضرورية فعلًا — الأثر الإجمالي المقيس موصوف في «الخمول الهادئ»؛ وهذه هي الطريقة الوحيدة من بين المُختبرة التي أعطت غيغابايتات، وثمنها فقدان الوظائف المقابلة؛
- تقييم النتيجة عبر commit والذاكرة المتاحة (Task Manager → «الأداء» → «الذاكرة»)، وليس عبر سطر «متاح».
ما لا يعمل:
- الإنهاء القسري لعمليات النظام: يعيد Windows تشغيلها خلال ثوانٍ، ويرتفع commit؛
- «محسّنات RAM» وتنظيف standby: الصفحات المُفرغة تبقى في RAM كذاكرة مؤقتة، وإعادتها إلى العمل تكلف أخطاء صفحات لينة؛
- معاملات السجل الخاصة بمدير الذاكرة.
ذاكرة standby ليست مشكلة بل عمل الذاكرة المؤقتة: فـ«المتاحة» تتضمنها أصلًا. واترك pagefile تحت إدارة النظام: فهو ضروري لحد الالتزامات في الذاكرة ولتفريغات الأعطال.
استعادة الحالة
Section titled “استعادة الحالة”أُجريت الاختبارات في جهاز افتراضي معزول على فروع حالة اختبارية؛ وبعد القياسات أُعيد ضبط الفروع الاختبارية، وأُعيد الجهاز إلى حالته الأصلية. لا توصي المقالة بإنهاء عمليات النظام أو تعطيل pagefile، لذلك لا يلزم إجراء استعادة منفصل على حاسوب المستخدم.
مصادر أولية عامة
Section titled “مصادر أولية عامة”- Microsoft: Working Set — تكوين working set، وإفراغ الصفحات، والصفحات الانتقالية المخزنة مؤقتًا في RAM، ودوال
EmptyWorkingSet/SetProcessWorkingSetSize؛ تم التحقق في 2026-09-20. - Microsoft: EmptyWorkingSet — الواجهة البرمجية التي تستخدمها أدوات «تحسين الذاكرة»؛ تم التحقق في 2026-09-20.
- Microsoft: About Memory Management — نموذج الذاكرة الافتراضية والصفحات المشتركة؛ تم التحقق في 2026-09-20.
- Microsoft: Introduction to the page file — commit charge، وحد الالتزامات ودور pagefile؛ تم التحقق في 2026-09-20.
- Memory Manager وذاكرة النظام المؤقتة — دراسة معاملات السجل الخاصة بمدير الذاكرة.
- الخمول الهادئ: خلفية Windows قبل التحسين وبعده — بروتوكول القياسات وبقية مقاييس هذا الاختبار نفسه.
- كيف نبحث Windows — مستويات الأدلة وقواعد القياسات.
سجل التغييرات
Section titled “سجل التغييرات”- 2026-09-20: تمت مواءمة الأرقام مع جداول السلاسل: «بعد» السلسلة 1 — 1 868/660 ميجابايت، وتم توضيح إسناد النسب حسب المقاييس والسلاسل؛ وتم تعزيز إخلاء المسؤولية بشأن تضارب المصالح إلى الصيغة الكاملة.
- 2026-09-20: النشر الأول — جرد الذاكرة في سلسلتين، والتجارب السلبية مع إنهاء العمليات والتنظيف، والزيادة الصادقة للتعطيلات المحددة.