בטלה שקטה: רקע 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 GB 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 שניות (לפי תהליכים);
- שלב “לאחר האתחול” הופעל באמצעות אתחול מבוקר והופעל בזמן פעילות (uptime) של כדקה;
- בכל תצורה נבדק מספר האירועים האבודים — בכל החלונות המוצגים הוא שווה לאפס;
- הממוצע חושב רק על פני מרווחים מלאים של חמש שניות בתוך גבולות השלב (59 מרווחים לשלב);
- בסדרה 2 ההרצה הראשונה של “לפני” הוצאה בגלל מעבר המכונה הווירטואלית למצב שינה; נעשה שימוש בחזרה;
- בדיקות העומס בוצעו פעמיים, מוצגים החציונים; תפוסת ה-CPU מנורמלת לארבעה vCPU.
“לפני” ו“אחרי” הם מצבים של אותה התקנת Windows: “אחרי” התקבל בהחלת פרופיל האופטימיזציה, “לפני” — המצב המקורי. שונה מכלול ההגדרות כולו, ולכן התרומה המבודדת של השבתה בודדת לא הוערכה.
תוצאות
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 % |
| זיכרון זמין, 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 מבצע תחזוקה, השבתת רכיבי הרקע חוסכת יותר; כאשר החלון כבר שקט — פחות.
הדקות הראשונות לאחר האתחול
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 |
| זיכרון פיזי תפוס, MB | — | 2 821 → 1 581 |
| זיכרון זמין, MB | — | 5 370 → 6 610 |
| קריאה מהדיסק, KB/שנייה | — | 826 → 433 |
| כתיבה לדיסק, KB/שנייה | 634 → 418 | 709 → 298 |
| רשת (קליטה), KB/שנייה | — | 1,15 → ~0 |
מקף משמעו שבסדרה זו המדד עבור השלב לא נרשם.
הרכב וזיכרון
Section titled “הרכב וזיכרון”צילום מלאי במצב בלתי פעיל (סדרה 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».
תחת עומס מלא
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 ms) | +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 במצב בלתי פעיל לאחר האופטימיזציה כמעט ריק.
לאן הולך הרקע
Section titled “לאן הולך הרקע”מקורות פעילות הרקע שנמדדו במצב “לפני”:
- סריקה אנטי-וירוסית — המקור העיקרי בחלון של סדרה 2: התהליך
MsMpEng.exeצרך 212 שניות CPU במהלך חלון מצב בלתי פעיל של חמש דקות; - במצב המקורי פעלו שירות החיפוש, השירות SysMain, טלמטריה, מנהל ההדפסה ורכיבים אחרים — פרופיל האופטימיזציה מעביר למצב מושבת כ-50 שירותי רקע ו-58 משימות מתוזמנות;
- לאחר האתחול הפעילות מלווה את מתזמר העדכונים של Windows.
השבתת רכיבי הרקע אינה מבטלת את הרקע לחלוטין: במצב המאופטם המשיכה לפעול הערכת תאימות היישומים (כ-3,7 ms CPU בשנייה בחלון התחזוקה), והרקע השיורי הכולל במצב בלתי פעיל מבוסס הסתכם ב-4,8 ms CPU בשנייה — כ-0,12 % מקיבולת ארבעת ה-vCPU (נמדד לפי תצורה).
מה אומת
Section titled “מה אומת”- שוחזר (שתי סדרות בלתי תלויות): מספר התהליכים −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 עצמה, כולל סריקה אנטי-וירוסית.
- נצפה: מקורות הרקע העיקריים — סריקה אנטי-וירוסית, תחזוקה ומשימות תאימות; לאחר האופטימיזציה הרקע השיורי קרוב לאפס, אך אינו אפס.
מה לא אומת
Section titled “מה לא אומת”- עלייה ב-FPS, הפחתת input lag או frametime במשחקים אמיתיים: לא נמדד. בדיקות CPU סינתטיות אינן מדמות משחק עם GPU ואינן מוכיחות אפקט במשחקים.
- התרומה המבודדת של כל השבתה בודדת: הוחל מכלול שינויים.
- העברת ערכים מוחלטים לחומרה פיזית, גרסאות אחרות ופרופילי אופטימיזציה אחרים.
- יציבות בחלונות ארוכים: כל שלב — 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. ככל שהמערכת עסוקה יותר ברגע ההשוואה, כך האפקט הנראה גדול יותר: בחלון תחזוקה ההבדל כפול ומכופל, בחלון שקט — מתון.
המלצה: העריכו את הרקע לפני ואחרי כל שינוי במחשב שלכם (Task Manager → “ביצועים” ו“תהליכים”, Resource Monitor), ואל תסתמכו על אחוזים של אחרים. אם המטרה היא 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 %); כתב הוויתור על ניגוד עניינים הובא לניסוח הקנוני.