כמה זיכרון באמת ניתן לפנות ב-Windows
בדף זה
תשובה קצרה
Section titled “תשובה קצרה”בפועל ניתן לשחרר פחות ממה ש“מייעלי זיכרון” מבטיחים. בניסוי הזה, השבתת רכיבי רקע שחררה 1.0–1.5 ג’יגה-בייט של זיכרון זמין והפחיתה את נפח ההתחייבויות (commit) ב-52% בסדרה 2. אבל השיטות המהירות הפופולריות לא עובדות: סיום תהליכי המעטפת — Windows מפעילה אותם מחדש בעצמה תוך כ-20 שניות; ניקוי working set — הדפים שהוצאו נשארים ב-RAM כמטמון; פרמטרי רישום של מנהל הזיכרון — אין תועלת מאומתת. השבתות ממוקדות מעל מערכת שכבר עברה אופטימיזציה הניבו +22–30 מגה-בייט אמיתיים. זיכרון ברשימת standby הוא מטמון שכבר נספר ב“זמין”.
סטטוס: המספרים הסופיים התקבלו במכונה וירטואלית עם 8 ג’יגה-בייט RAM על Windows 11 (26H2, build 26300.9457). הכיוונים מאומתים על ידי תיעוד Microsoft והניסויים המבוקרים שלנו; הערכים המוחלטים בתצורה אחרת יהיו שונים.
טענות לבדיקה
Section titled “טענות לבדיקה”בדקנו ארבע טענות:
- סיום תהליכי רקע “מיותרים” משחרר זיכרון.
- ניקוי working set או רשימת standby (המכניקה של “מייעלי RAM”) משחרר זיכרון.
- פרמטרי רישום של מנהל הזיכרון משחררים זיכרון באופן ניכר.
- השבתת רכיבי רקע משחררת נפח זיכרון גדול.
תחום המחקר
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 של הרישום.
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 מגה-בייט עם גידול של 13 מגה-בייט ב-standby — הדפים שהוצאו נשארים במערכת כמטמון, והמעטפת והתהליכים הקשורים ממשיכים לפעול.
מסקנת הניסוי: סיום כפוי של תהליכי מערכת אינו משחרר זיכרון. 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%.
פרמטרי רישום של מנהל הזיכרון (גדלים של pools, מטמון מערכת ודומים) בניסוי הזה אפילו לא נשקלו כמקור לרווח: הקריאה שלהם והתועלת המעשית שלהם מנותחות ב«Memory Manager ומטמון המערכת» — אין להם תועלת מאומתת לשחרור RAM.
מה אומת
Section titled “מה אומת”- שוחזר (שתי סדרות): השבתת רכיבי רקע משחררת 1.0–1.5 ג’יגה-בייט של זיכרון זמין; סה“כ working set הצטמצם ב-51% (סדרה 1), הזיכרון התפוס — ב-49% ונפח ההתחייבויות (commit) — ב-52% (סדרה 2).
- נמדד: הפעלה מחדש אוטומטית של תהליכי מעטפת שהופסקו בתוך 20 שניות; ה-commit לא יורד (בניסוי שלנו עלה ב-12.6 מגה-בייט).
- נמדד: סיום סייר אינו נותן גידול יציב בזיכרון הפנוי; הדפים שהוצאו נשארים ב-standby.
- מתועד: הוצאת דפים מ-working set מעבירה אותם למצב מעבר, במטמון ב-RAM; זיכרון standby נספר בזיכרון הזמין.
- נמדד: השבתות ממוקדות מעל מערכת שעברה אופטימיזציה נותנות +22–30 מגה-בייט של זיכרון פנוי בביצועים ללא שינוי; סכום working set של המושבת אינו שווה לתוספת בזיכרון הפנוי.
מה לא אומת
Section titled “מה לא אומת”- “מייעלי RAM” של צד שלישי לא נבדקו ישירות: נבדקה המכניקה (ניקוי working set) שעליה הם בנויים.
- השבתת pagefile לא נמדדה; ידוע רק ש-pagefile נדרש ל-crash dump ולמגבלת התחייבויות הזיכרון.
- העברת הערכים למכונות עם נפח RAM אחר, builds אחרים וחומרה פיזית.
- יציבות החיסכון בחלונות ארוכים: המדידות בוצעו בעמידה שקטה מבוססת.
מגבלות
Section titled “מגבלות”- מכונה וירטואלית עם 8 ג’יגה-בייט RAM: המספרים המוחלטים קשורים לתצורה הזו; פרופיל עם נפח גדול יותר של רכיבי רקע ישחרר יותר, מערכת “שקטה” — פחות.
- סכום working set לפי תהליכים מנפח את העקבות הייחודיות בגלל דפים משותפים; אנחנו מביאים לצדם private bytes בדיוק משום כך.
- שכבת המדידה עצמה תפסה זיכרון ניכר (עד מאות מגה-בייט של working set במדידות מסוימות) — המספרים של המצב כוללים את נוכחות המדידה.
- לא היה pressure על הזיכרון בניסוי (hard faults נמוכים), ולכן לא בדקנו אם החיסכון מפחית thrashing בתנאי מחסור ב-RAM.
- חלק מהשחרור קשור להשבתת רכיבי ההגנה של Microsoft Defender — זהו פשרה עם האבטחה, ולא זיכרון שהתקבל בחינם.
המחקר והכלים שבהם נעשה שימוש שייכים למפתח של BoosterX, ו-BoosterX הוא מייעל Windows, ולכן מדידת אפקט האופטימיזציה היא האינטרס הישיר שלו. המתודולוגיה וגבולות התחולה מתוארים לעיל, ואת המסקנות ניתן לבדוק לפי הנתונים הפתוחים והמקורות הציבוריים המפורטים. תוצאות שליליות לגבי שיטות פופולריות ל“שחרור זיכרון” פורסמו באותה מידה כמו החיוביות.
מסקנה מעשית
Section titled “מסקנה מעשית”מה שבאמת משחרר זיכרון, לפי הניסוי הזה:
- לסגור אפליקציות שאינן בשימוש — ה-private bytes שלהן משוחררים במלואם;
- להשבית רכיבי רקע שבאמת אינם נחוצים — האפקט המצטבר הנמדד מתואר ב«עמידה שקטה»; זו הדרך היחידה מבין הנבדקות שהניבה ג’יגה-בייטים, ומחירה — אובדן הפונקציות המתאימות;
- להעריך את התוצאה לפי commit והזיכרון הזמין (מנהל המשימות → “ביצועים” → “זיכרון”), ולא לפי השורה “פנוי”.
מה לא עובד:
- סיום כפוי של תהליכי מערכת: 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 — ה-API שבו משתמשים כלי “אופטימיזציית זיכרון”; נבדק 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: פרסום ראשון — מלאי זיכרון בשתי סדרות, ניסויים שליליים עם סיום תהליכים וניקוי, התוספת האמיתית של השבתות ממוקדות.