זמן סרק שקט: פעילות הרקע של Windows לפני ואחרי האופטימיזציה
בדף זה
תשובה קצרה
Section titled “תשובה קצרה”השבתת רכיבי רקע של Windows אכן הופכת את זמן הסרק לשקט יותר: בשתי סדרות מדידה בלתי תלויות מספר התהליכים ירד ב־49–56 %, ניצולת ה־CPU בזמן סרק ירדה ב־17–67 %, וכמות התחייבות הזיכרון (commit) ירדה ב־52 % בסדרה השנייה. אבל תחת עומס CPU מלא, התפוקה גדלה רק ב־0,2–0,5 %. «זמן סרק שקט» הוא צמצום מאומת של עבודת הרקע והתחרות על משאבים, ולא עלייה ב־FPS: ההשפעה הסופית על משחקים לא נמדדה במחקר הזה.
סטטוס: כיוון ההשפעה שוחזר בשתי סדרות בלתי תלויות באותו build של 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 (ה-build העדכני במועדי המדידה);
- שתי סדרות מדידה בלתי תלויות: 2026-09-18 ו־2026-09-19; המצבים הושוו בעותקים עצמאיים של הדיסק, כדי שהמדידות לא ישפיעו זו על זו;
- שלבים: 5 דקות לאחר האתחול, 5 דקות התייצבות, 5 דקות סרק;
- עומסים סינתטיים קצרים: 1, 4 ו־8 threads, עומס זיכרון, עומס מתוזמן ותערובות של רמות עדיפות.
המדידות לא כללו משחקים אמיתיים, עומס GPU, חומרה פיזית או חלונות זמן ממושכים (שעות וימים).
סדרה נפרדת במחשב פיזי Ryzen 7 7800X3D, שכללה ארבעה שלבים ומדידות במשחקים, פורסמה במאמר «BoosterX: רקע Windows ו־FPS ב־CS2». תוצאותיה אינן משולבות בסדרה זו, שנערכה במכונות וירטואליות.
מתודולוגיה
Section titled “מתודולוגיה”הפרוטוקול תואם ל־«כיצד אנו חוקרים את Windows»:
- כל שלב תועד באמצעות מעקב ETW (Windows Performance Recorder, פרופילים קלים של CPU, דיסק, קבצים ורשת) ומוני ביצועים במרווחים של 5 שניות (מערכת) ו־15 שניות (לפי תהליך);
- שלב «לאחר האתחול» התחיל באתחול מחדש מבוקר ונכלל כאשר זמן הפעולה היה כדקה;
- בכל מעקב נבדק מספר האירועים שאבדו — בכל החלונות המוצגים הוא אפס;
- הממוצע חושב רק על פני מרווחים מלאים של חמש שניות בתוך גבולות השלב (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 % |
| Threads (ממוצע) | 1 444,6 | 738,7 | −49 % |
| CPU כולל של כל התהליכים, % | 1,22 | 1,06 | −13 % |
| זיכרון זמין, MB | 5 490 | 6 518 | +1 028 |
| קריאה מהדיסק, KB/s | 22,6 | 24,4 | +8 % |
| כתיבה לדיסק, KB/s | 311,3 | 262,1 | −16 % |
| רשת (קבלה), KB/s | 132,6 | 2,2 | −98 % |
| רשת (שליחה), KB/s | 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 % |
| Threads (ממוצע) | 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/s | 7,42 | 0,01 | −99,9 % |
| כתיבה לדיסק, MB/s | 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 |
| Threads | — | 1 719 → 746 |
| זיכרון פיזי בשימוש, MB | — | 2 821 → 1 581 |
| זיכרון זמין, MB | — | 5 370 → 6 610 |
| קריאה מהדיסק, KB/s | — | 826 → 433 |
| כתיבה לדיסק, KB/s | 634 → 418 | 709 → 298 |
| רשת (קבלה), KB/s | — | 1,15 → ~0 |
מקף מציין שהמדד לא תועד בשלב הזה בסדרה זו.
הרכב וזיכרון
Section titled “הרכב וזיכרון”תמונת מצב של המלאי בזמן סרק (סדרה 1):
| לפני | אחרי | |
|---|---|---|
| תהליכים | 136 | 70 |
| Threads | 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: לפני / אחרי |
|---|---|---|
| Thread אחד | +5,4 % | 21,9 / 22,6 % |
| ארבעה Threads (מלא) | +0,19 % | 88,9 / 89,4 % |
| שמונה Threads (מלא) | +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 % |
בעומס מלא של ארבעה Threads, התהליך שביצע את העבודה קיבל כ־89 % מהקיבולת של ארבעת ה־vCPU, גם לפני האופטימיזציה וגם אחריה. את כ־11 % הנותרים במכונה הווירטואלית אי אפשר להגדיר כ«רעש Windows» שניתן להסרה: תזמון ההיפרוויזור אינו גלוי במעקב של מערכת האורח. Threads העבודה חולקו באופן אחיד (ההפרש בכמות העבודה ביניהם — 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 %, מספר ה־Threads −49…−57 %, זיכרון זמין +1,0–1,5 GB.
- נמדד (סדרה 2): commit ירד ב־52 % בזמן סרק; הזיכרון הפיזי בשימוש ירד ב־49 % בזמן סרק וב־44 % בשלב שלאחר האתחול.
- נמדד: ניצולת ה־CPU בזמן סרק ירדה ב־17 % בחלון שקט וב־67 % בחלון שבו התבצעה סריקה; החלפות הקשר ירדו ב־19 % וב־92 %; DPC ירד ב־78 % (חלון סדרה 2); הפעילות לאחר האתחול הייתה נמוכה יותר בשתי הסדרות.
- נמדד: תחת עומס CPU מלא, התפוקה עלתה ב־+0,19 % (4 Threads) וב־+0,50 % (8 Threads); בעומס חלקי ומעורב — מ־+5,4 עד +11,2 %.
- נמדד: עומס בעדיפות רקע הואץ ב־77,1 % — במצב «לפני» הוא התחרה בעבודת הרקע של Windows עצמה, לרבות סריקת אנטי־וירוס.
- נצפה: המקורות העיקריים לפעילות הרקע הם סריקת אנטי־וירוס, תחזוקה ומשימות תאימות; לאחר האופטימיזציה פעילות הרקע שנותרה קרובה לאפס, אך אינה אפס.
מה לא אושר
Section titled “מה לא אושר”- עלייה ב־FPS, ירידה ב־input lag או ב־frametime במשחקים אמיתיים: לא נמדדו. בדיקות CPU סינתטיות אינן מדמות משחק עם GPU ואינן מוכיחות השפעה על משחקים.
- התרומה המבודדת של כל השבתה בנפרד: הוחל מכלול של שינויים.
- החלת הערכים המוחלטים על חומרה פיזית, builds אחרים ופרופילי אופטימיזציה אחרים.
- יציבות בחלונות זמן ארוכים: כל שלב נמשך 5 דקות; עבודת הרקע של Windows מגיעה בהתפרצויות, ולכן «יום ממוצע» לא נמדד.
מגבלות
Section titled “מגבלות”- המדידות בוצעו במכונה וירטואלית. הווירטואליזציה מוסיפה חלק משלה ל־DPC/ISR ומסתירה את תזמון המארח; הערכים המוחלטים בחומרה פיזית יהיו שונים. היחסים וכיוון ההשוואה «לפני/אחרי» נשמרים בתנאים זהים.
- מדד ISR הושמט מהטבלאות: במכונה הווירטואלית, מונה ISR של PDH שונה ממוני מטפלי הפסיקות של ETW בכ־10 % ואינו מסתכם לערך מדויק.
- חלון «לפני» של סדרה 2 כלל סריקה פעילה של Defender, ועומס המארח היה שונה בין החלונות (ממוצע של 44 % לעומת 24 %). לכן הערכים מתייחסים לחלונות המסוימים האלה; כיוון ההשפעה אושר בשתי סדרות.
- בסדרה 1, חלק משלב הסרק נקטע עקב השהיה חיצונית של המכונה הווירטואלית למשך כ־26 שניות; הלכידה הסתיימה לאחר החידוש, ולא אבדו אירועים.
- בדיקות העומס כללו שתי חזרות: מדובר בסטטיסטיקה תיאורית, ומובהקות סטטיסטית לא הוערכה.
- חלק מהשיפור בזמן סרק קשור להשבתת רכיבי ההגנה של Microsoft Defender. מערכת ללא הגנת אנטי־וירוס היא פשרה מודעת, ולא אופטימיזציה נטולת מחיר; יש להשבית את ההגנה רק מתוך הבנת המחיר.
- שכבת המדידה (מעקב ומונים) יוצרת בעצמה עומס רקע קטן; הוא קיים בשני המצבים.
המחקר והכלים שבהם נעשה שימוש שייכים למפתח של BoosterX, ולכן למפתח יש עניין ישיר בתוצאות. המתודולוגיה ומגבלות התחולה מתוארות לעיל, וניתן לבדוק את המסקנות באמצעות הנתונים הפתוחים והמקורות הציבוריים המפורטים.
מסקנה מעשית
Section titled “מסקנה מעשית”צמצום רעש הרקע הוא השפעה ממשית ששוחזרה פעמיים: כמחצית ממספר התהליכים וה־Threads, כמחצית מהתחייבות הזיכרון, וסדר גודל פחות של פעילות דיסק ורשת בזמן סרק. יש לכך תועלת בפני עצמה — לתגובתיות המערכת, למשימות רקע, לטמפרטורה, לרעש המאווררים ולזמן העבודה מהסוללה — ואין צורך להבטיח עלייה ב־FPS.
מה לא כדאי לצפות לו: עלייה בביצועים תחת עומס מלא. אם ה־CPU כבר עסוק בעבודה מועילה בכ־89 % מהקיבולת, השבתת פעילות הרקע לא תוסיף את 11 % הנותרים — במכונה הווירטואלית הם אינם שייכים ל־Windows. ככל שהמערכת עסוקה יותר בזמן ההשוואה, כך ההשפעה הנראית גדולה יותר: בחלון תחזוקה ההפרש גדול פי כמה, ובחלון שקט הוא מתון.
המלצה: בדקו את פעילות הרקע לפני ואחרי כל שינוי במחשב שלכם (Task Manager → «ביצועים» ו«תהליכים», צג המשאבים), ואל תסתמכו על אחוזים של אחרים. אם המטרה היא 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 %); כתב הוויתור על ניגוד העניינים הותאם לנוסח הקנוני.