דיסק ב-100%: מה באמת צריך לעצור? — להפריד בין SysMain, Windows Search ו-Defender

פותחים את Task Manager והדיסק ב-100%. פתיחת אפליקציה איטית; גם הקלדה. ואז מוצאים את העצה — “לכבות SysMain”, “לעצור Windows Search”, “לכבות Defender” — והרפלקס הוא לעצור הכול.

מה שצריך להפריד כאן הוא “מה קורא וכותב” ו”למה הפעולות שלכם ממתינות”. השמות בראש Task Manager לבדם לא עושים את ההבחנה הזו.

המאמר מיועד בעיקר למשתמשי Windows 11 יומיומיים. הוא מסביר איך לקרוא את התצוגה, מה שלוש היכולות עושות, ונוהל חקירה שאפשר להחזיר ממנו את ההגדרות. שמות מסכים ויכולות זמינות משתנים לפי build של Windows ומדיניות ניהול. שלבים שמיועדים למנהלים מסומנים כך. המקורות הם תיעוד ראשוני של Microsoft, שנבדק ב-5 בספטמבר 2026. זה אינו מאמר שמדד שיעורי שיפור במכונה מסוימת.

1. קודם המסקנה: לא עוצרים את שלושתם באותו אופן

הסדר שהמאמר ממליץ עליו הוא תצפית → צמצום היעד → שינוי אחד → החזרה והשוואה. שומרים קבצים חשובים, ובמחשב בניהול החברה מתייעצים עם המנהל לפני שינוי הגדרות.

הטבלה הזו אינה דירוג פשוט של כמה מסוכן לעצור כל אחת. ל-SysMain, ל-Search ול-Defender יש תפקידים נפרדים: שמירה ושיפור של ביצועי המערכת, בניית index לחיפוש, והגנה מפני malware. גם מה שמאבדים שונה לכל אחת.¹²³

flowchart TB
    accTitle: הסדר הבסיסי לחקירת דיסק ב-100%
    accDescr: כשרואים דיסק ב-100%, מתבוננים בפעולות האיטיות וביעד, משווים שינוי בודד, ומחזירים, לפי הסדר.
    A["דיסק 100% ופעולות איטיות"] --> B["רושמים את חלון הזמן ואת היעד"]
    B --> C["בודקים השערה אחת"]
    C --> D["מחזירים ובודקים שוב"]
    D --> E["משאירים רק את האמצעים שצריכים"]

איור 1: לפני שינוי הגדרות בכמות, יוצרים מצב שאפשר להשוות אליו.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 13, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. 100% אינו “מלא” ואינו “מהירות שיא”

פותחים את הדיסק הרלוונטי תחת Performance ב-Task Manager ורואים זמן פעילות, מהירות קריאה וכתיבה, וזמן תגובה ממוצע. חלק הזמן שהדיסק היה עסוק וכמות הנתונים שהזיז הם שני דברים שונים. גם מחסור במקום פנוי צריך בדיקה נפרדת.

למשל, אם כל בקשה בודדת צריכה להמתין, כמות הנתונים שעוברת נשארת קטנה גם כשהדיסק עובד ברציפות. זה כמו ההבדל בין הובלת ארגזים גדולים בכמות לבין מסירת ארגזים קטנים אחד-אחד. קריאות וכתיבות קטנות, או latency בצד האחסון, יכולים לדחוף את הדיסק קרוב ל-100% ב-כמה MB/s בלבד. גם תיעוד troubleshooting הביצועים של Microsoft בודק זמן תגובה של I/O, לא רק throughput.⁴

לכן גם “זה 100%, אז ה-SSD מנוצל במהירות המלאה” וגם “זה רק כמה MB/s, אז הדיסק אינו הסיבה” הם מוקדמים. קודם מסתכלים יחד על מספר הדיסק ועל אות הכונן שבהם הבעיה מתרחשת. אם C: ו-D: נמצאים על אותו דיסק פיזי, עבודה על D: יכולה להתחרות בפעולות בצד C:.

flowchart TB
    accTitle: שלושה מדדים להסתכלות על דיסק
    accDescr: זמן פעילות, throughput וזמן תגובה הם מדדים נפרדים, וצריך לראות אותם יחד לאותו חלון זמן.
    A["מתבוננים באותו חלון זמן"] --> B["עסוקות: זמן פעילות"]
    A --> C["נפח: מהירות קריאה/כתיבה"]
    A --> D["המתנה: זמן תגובה"]
    B --> E["משווים מול הפעולות האיטיות"]
    C --> E
    D --> E

איור 2: אחוז לבדו לא אומר אם הנפח גבוה או שההמתנה ארוכה.

3. התצפית הראשונה: מתי, ועל אילו קבצים, זה נהיה איטי

עדיין לא עוצרים אף service; פותחים את Task Manager ב-Ctrl + Shift + Esc. ממיינים לפי עמודת Disk תחת Processes, ובאותו זמן בודקים את הדיסק הרלוונטי תחת Performance. אחר כך מפעילים resmon.exe מ-Win + R ותחת Disk ב-Resource Monitor מסתכלים על שם התהליך, הקובץ, קריאות, כתיבות וזמן תגובה. אם אין מספיק מידע, מבקשים ממנהל לחקור.⁵

קושרים את הרישום למה שעשיתם: “שלוש דקות אחרי האתחול”, “בזמן חילוץ ZIP”, “עד שהסנכרון נגמר”. במקום רגע בודד על המסך, המאמר ממליץ להשוות לפני שהיה איטי, בזמן שהיה איטי, ואחרי שהתאושש. מצב שבו עדכון או העתקה בתהליך ונרגע כשהם מסתיימים דורש צעד הבא שונה ממצב שבו אותה פעולה קטנה נתקעת לאורך זמן בכל פעם.

שימו לב שזמן התגובה הממוצע אינו המקרה הגרוע ביותר של פעולה בודדת. לא מכריזים על כשל לפי מספר גבוה אחד; בודקים מול תקיעות ושגיאות שחוזרות. גם כש-System או svchost.exe קרובים לראש, לא הורגים אותם בכוח לפי השם בלבד. System מכסה גם עבודת kernel ו-driver.⁴

flowchart TB
    accTitle: רישום התצפית ששומרים לחקירה
    accDescr: החל מהזמן והפעולה שהאטו, רושמים את הדיסק, התהליך, הקבצים, ואת התנאים שבהם זה התאושש.
    A["פעולה איטית וזמן"] --> B["בודקים את הדיסק הרלוונטי"]
    B --> C["מסתכלים על תהליכים וקבצים"]
    C --> D["ממשיכים להתבונן אחרי שזה נגמר"]
    D --> E["רושמים את תנאי ההתאוששות"]

איור 3: משאירים רישום שאפשר לשחזר ממנו את הבעיה, לא רק “זה היה כבד”.

4. לראות שם אינו אותו דבר כמו למצוא את שורש הסיבה

כשאפליקציה שיוצרת מספר גדול של קבצים רצה, לכתיבות שלה עצמה עשויים להצטרף עדכוני search index וסריקות אבטחה. Search מאנדקס מידע על קבצים לצורך חיפוש, ו-Defender סורק קבצים ותהליכים.²⁶

מה שבא הוא דוגמה לחשיבה על סיבות. גם אם עומס Defender עולה בזמן שכלי חילוץ יוצר מספר גדול של קבצים, זה לא בהכרח אומר “רק Defender שבור”. קצב יצירת הקבצים, תיקיית היעד, ותגובת האחסון עשויים כולם לתרום יחד.

ולהפך, להחליט שיכולת אינה רלוונטית כי היא חלק לגיטימי מ-Windows היא גם טעות. גם יכולת נחוצה יכולה להפוך לגורם מתחרה בסביבה אמיתית. מה שרוצים לדעת אינו מי אשם, אלא איזו עבודה, שמופחתת בכמה, משפרת את המשימות שצריכים.

flowchart TB
    accTitle: דוגמה למשימה אחת שמייצרת כמה קריאות וכתיבות
    accDescr: מראה שליצירת קבצים המונית עשויים להצטרף עדכוני index אם הקבצים באינדקס, וסריקות אם הם מוגנים.
    A["יצירת קבצים המונית"] --> B["הכתיבות של האפליקציה עצמה"]
    A -.-> C["עדכון index אם באינדקס"]
    A -.-> D["סריקה אם מוגן"]
    B --> E["יכולים להתחרות באותו יעד"]
    C --> E
    D --> E

איור 4: העבודה בקו המקווקו לא בהכרח מתרחשת בכל פעם; אלה יחסי המועמדים לחקירה.

5. SysMain: משאירים, ומשווים זמנית רק כשיש חשד

ברשימת ה-services של Microsoft, SysMain הוא ה-service שמטרתו שמירה ושיפור של ביצועי המערכת. המסמך הזה שם אותו בקטגוריה שלא מכבים. שימו לב, עם זאת, שהמסמך מכסה Windows IoT Enterprise; זו אינה הבטחה מדודה ש”כל מחשב Windows 11 רגיל בטוח יאיץ”.¹

המאמר אינו ממליץ להגדיר את סוג ההפעלה ל-Disabled על סמך קריאת דיסק 100% לבדה. אם המספר יורד מיד אחרי עצירת ה-service, ייתכן שפשוט פחות עבודת רקע מתבצעת. מסתכלים עד האם זמני פתיחת אפליקציות והעבודה היומיומית באמת השתפרו.

מרחיבים את קבוצת Service Host ב-Task Manager כדי לבדוק את הקשר, ורק אם מתקבל חומר שמפליל את SysMain, מריצים השוואה קצרה כמנהל. לפני העצירה, רושמים ב-services.msc את הסטטוס ואת סוג ההפעלה של SysMain. עצירה זמנית של service והגדרה שלא יתחיל בפעם הבאה הן פעולות שונות.⁷⁸

flowchart TB
    accTitle: ההבדל בין השוואת SysMain זמנית לכיבוי קבוע
    accDescr: בחקירה הזו עוצרים זמנית service שרץ ומשחזרים אותו, בנפרד משינוי קבוע בהגדרת ההפעלה.
    A["בודקים את הקשר ל-SysMain"] --> B["רושמים את המצב המקורי"]
    B --> C["עוצרים זמנית אם רץ"]
    C --> D["משווים את אותה פעולה"]
    D --> E["מפעילים מחדש ומאשרים"]
    B -.-> F["לא נוגעים בהגדרת ההפעלה"]

איור 5: לא מבלבלים בין “עוצרים ורואים את ההבדל” לבין “משאירים כבוי”.

למנהלים: השוואה של 90 שניות ושחזור כצעד אחד

הבאה היא דוגמה שרצה כבלוק שלם ב-Windows PowerShell 5.1 שנפתח כמנהל. היא מכוונת רק ל-SysMain שכבר רץ, ובמהלך 90 השניות אחרי שהוא נעצר מנסים את אותה משימה בחלון אחר. היא לא משנה את סוג ההפעלה.

# מריצים את כל הבלוק ב-Windows PowerShell 5.1 כמנהל.
$service = Get-Service -Name SysMain -ErrorAction Stop
if ($service.Status -ne 'Running') {
    throw 'SysMain אינו רץ. יוצאים בלי לשנות את ההגדרות הנוכחיות.'
}

try {
    Stop-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Stopped', [TimeSpan]::FromSeconds(30))
    Write-Host 'במשך 90 שניות, השוו את אותה פעולה בחלון אחר.'
    Start-Sleep -Seconds 90
}
finally {
    Start-Service -Name SysMain -ErrorAction Stop
    $service.WaitForStatus('Running', [TimeSpan]::FromSeconds(30))
    Get-Service -Name SysMain | Select-Object Name, Status
}

finally קיים כדי לנסות את השחזור ביציאה רגילה או ב-exception. הוא אינו מבטיח שחזור כשחלון PowerShell נסגר בכוח, התהליך נהרג, או החשמל נקטע. אם ההרצה נקטעה באמצע, בודקים את הסטטוס ב-services.msc, ואם ה-SysMain שעצרתם בנוהל הזה עדיין עצור, מפעילים אותו. אם השחזור נכשל, לא משאירים כך; מתייעצים עם מנהל.⁹

flowchart TB
    accTitle: בדיקות בסיום ניסוי העצירה הזמנית
    accDescr: בדרך כלל finally מנסה את ההפעלה מחדש; אחרי סגירה כפויה או כשל בהפעלה מחדש, בודקים את הסטטוס במסוף Services.
    A["מסיימים את ההשוואה"] --> B{"ההפעלה מחדש אושרה?"}
    B -->|"כן"| C["משווים שוב במצב המקורי"]
    B -->|"לא"| D["בודקים במסוף Services"]
    D --> E["מפעילים או מתייעצים עם מנהל"]

איור 6: גם עם קוד שמשחזר אוטומטית, לא מדלגים על בדיקת הסטטוס הסופית.

6. Windows Search: לפני שעוצרים, חוזרים ל”מה אני רוצה לחפש?”

ה-index של Windows Search הוא מנגנון למציאה מהירה של שמות קבצים, תוכן ועוד. עבודה מתרחשת בזמן שה-index נבנה או מתעדכן, אבל זו גם הכנה כדי שהחיפוש יהיה מהיר.²

ב-Windows 11 פותחים הגדרות → פרטיות ואבטחה → חיפוש ב-Windows ובודקים את התקדמות ה-indexing ואת טווח החיפוש. אם השמות שונים ב-build שלכם, מחפשים “index” בתוך הגדרות. אם נכללים מספר גדול של קבצים שמעולם לא משתמשים בהם, אפשר לצמצם את הטווח עם Excluded folders, או עם Modify תחת Indexing Options.¹⁰

למשל, node_modules ופלט build במחשב פיתוח הם מועמדים לבחינה אם אין צורך למצוא אותם דרך חיפוש Windows. זו אינה, עם זאת, המלצה להוציא הכול לפי שם תיקייה באופן גורף. חושבים קודם האם מקובל שתוכן של מיקום שהוסר מהחיפוש כבר לא יימצא כמו קודם. אם רושמים את הטווח לפני השינוי, אפשר לחזור אם החיפוש נהיה בעיה.

“הוצאה מהחיפוש” כאן שונה מ”הוצאה מההגנה של Defender”, שמתוארת בהמשך. לא משנים את שתי ההגדרות בבת אחת.¹¹³

flowchart TB
    accTitle: החלטה לצמצם את טווח החיפוש
    accDescr: בודקים אילו תיקיות באינדקס וחוזרים על הטווח לפי הצורך למצוא את המיקום דרך חיפוש Windows.
    A["בודקים את המיקומים באינדקס"] --> B{"נחוץ לחיפוש?"}
    B -->|"נחוץ"| C["משאירים באינדקס"]
    B -->|"לא נחוץ"| D["רושמים, ואז בוחנים מחדש את הטווח"]
    D --> E["בודקים עומס ותוצאות חיפוש"]

איור 7: לפני שעוצרים לגמרי את יכולת החיפוש, שוקלים אם אפשר להקטין את כמות המידע שמוכן.

לא מתייחסים ל-Rebuild ככפתור תיקון של “לוחצים ורואים”

בנייה מחדש של ה-index יוצרת את ה-index מאפס. אם הוא כבר נבנה, העבודה הזו מתחילה שוב מההתחלה. Microsoft ממליצה להקצות עד כ-24 שעות ל-rebuild, ותוצאות החיפוש יכולות להיות חלקיות בזמן שהוא רץ.¹⁰

לכן לבנות שוב ושוב רק כי הדיסק עסוק אינו מומלץ. בודקים קודם התקדמות ושגיאות, ומריצים rebuild כשזה באמת נחוץ, למשל אחרי התאמת הטווח או כשתוצאות החיפוש שגויות. אם מריצים, מחברים את המחשב לחשמל, מקצים מספיק זמן לעבודה להסתיים, ומבחינים בין העומס בזמן ה-rebuild לבין העומס במצב יציב.

flowchart TB
    accTitle: הפרדה בין במהלך rebuild של index לבין אחריו
    accDescr: rebuild כולל את עומס יצירת ה-index מחדש ופער זמני בתוצאות החיפוש; שופטים את האפקט אחרי הסיום.
    A["מאשרים את הצורך, ואז rebuild"] --> B["התקופה שבה ה-index נוצר מחדש"]
    B --> C["מחכים לסיום"]
    C --> D["בודקים תוצאות חיפוש ועומס"]

איור 8: לא שופטים אם האמצעי עבד לפי העסוקות מיד אחרי תחילת rebuild.

7. Defender: מבררים “מה נסרק” בלי לכבות הגנה

גם כש-Antimalware Service Executable או MsMpEng.exe בולטים, כיבוי real-time protection כהאצה יומיומית אינו מומלץ. כל עוד ההגנה כבויה, קבצים שפותחים או מורידים כבר לא נסרקים כרגיל. גם אם מספר הדיסק יורד, אם איבדתם יכולת שצריכים, זה לא נהיה מהיר יותר באותם תנאים.³

מה שאפשר להשתמש בו לחקירה הוא מנתח הביצועים של Microsoft Defender Antivirus. הוא מתעד סריקות ומדווח על הקבצים שלקח זמן רב לסרוק ועל התהליכים הקשורים. זה אינו כלי שמודד את כל ה-latency של הדיסק בכל המחשב. מטרתו להיות משולב עם חלון הזמן האיטי שראיתם ב-Resource Monitor, כדי לברר אם סריקת Defender מעורבת.⁶

flowchart TB
    accTitle: חקירת עומס Defender כשההגנה נשארת דולקת
    accDescr: משאירים real-time protection דולק בזמן שמתעדים את הפעולות האיטיות, ומשווים את דוח הסריקה מול זמני הפעולה.
    A["משאירים real-time protection דולק"] --> B["מתעדים את הפעולות האיטיות"]
    B --> C["דוח של זמני סריקה"]
    C --> D["משווים מול זמני ההמתנה בפועל"]
    D --> E["חוקרים גם יצירת קבצים וכדומה"]

איור 9: במקום להסיר יכולת אבטחה כדי להוריד מספר, מסתכלים ממה מורכב העומס.

למנהלים: מקליטים ומסתכלים על הפריטים בראש

הדרישות הרשמיות הן Windows 10 ואילך ופלטפורמת Defender 4.18.2108.X ואילך. נדרשות הרשאות Administrator. אם משתמשים במוצר אבטחה אחר, או שמדיניות הארגון מגבילה את היכולת, לא כופים את הנוהל הזה; בודקים מול המנהל או מול ערוץ התמיכה של המוצר.¹²

הבאה רצה ב-Windows PowerShell 5.1 שנפתח כמנהל. אחרי שההקלטה מתחילה, משחזרים את פעולת הבעיה בחלון אחר, ואז לפי ההנחיה בצד ההקלטה לוחצים Enter כדי לסיים. לבעיה יומיומית מצמצמים לחלון שחזור קצר במקום להקליט לאורך זמן.⁶

# מריצים ב-Windows PowerShell 5.1 כמנהל.
Get-Command New-MpPerformanceRecording, Get-MpPerformanceReport -ErrorAction Stop |
    Select-Object Name, Source

# משתמשים בשם ייחודי כדי לא לדרוס הקלטה קיימת.
$trace = Join-Path $env:TEMP ('Defender-' + [guid]::NewGuid().ToString('N') + '.etl')
Write-Host "יעד ההקלטה: $trace"
New-MpPerformanceRecording -RecordTo $trace -ErrorAction Stop

# קוראים את הדוח אחרי שההקלטה הסתיימה.
Get-MpPerformanceReport -Path $trace -TopFiles 10 -TopProcesses 10 -ErrorAction Stop

מה שמופיע כאן בראש הם הפריטים שהייתה להם ההשפעה הגדולה ביותר על הסריקה בחלון שהוקלט. זה לא אומר “מוציאים את העשירייה הראשונה וזה יאיץ בבטחה”. גם Microsoft אינה ממקמת את המנתח הזה ככלי להצעת exclusions.¹²

קודם מבררים מה ממשיך ליצור מחדש את הקובץ הזה, האם אותה עבודה משוכפלת, והאם אפשר להתאים בצד האפליקציה. אם exclusion באמת נחוץ, מנהל שמבין את היקף ההשפעה ואת הירידה בהגנה מחליט מקרה-מקרה. לא מוציאים את כל C: או את כל פרופיל המשתמש על סמך נוהל המאמר הזה לבדו. בהקלטה יש נתיבי קבצים ומידע על תהליכים, לכן בודקים איך מטפלים במידע סודי לפני שמעבירים אותו למישהו מבחוץ.

flowchart TB
    accTitle: סדר החקירה מדוח הניתוח
    accDescr: הפריטים בראש לפי עומס סריקה הם נקודת הכניסה לחקירה; בודקים את מקורם ואת התדירות לפני ששוקלים אמצעים.
    A["הפריטים בראש הדוח"] --> B["בודקים מקור ותדירות"]
    B --> C["שוקלים שיפורים בצד האפליקציה"]
    C --> D["אם צריך, מחליטים מקרה-מקרה עם מנהל"]
    A -.-> E["לא הופכים לרשימת exclusion כפי שהם"]

איור 10: הדוח הוא חומר לחקירת שורש, לא רשימת קבצים שבטוח להוציא מההגנה.

8. מעבר לשלושה: זיכרון ובריאות האחסון

אם זה נהיה איטי כשהרבה אפליקציות פתוחות, בודקים גם זיכרון ב-Task Manager. “Hard faults”, שבהם pages שאינם בזיכרון נקראים בחזרה מהאחסון, עשויים לעלות, אבל זה אינו אומר כשל דיסק פיזי. מקור הקריאה-בחזרה אינו רק ה-page file; זה יכול להיות קבצי הרצה, memory-mapped files ועוד. גם הערך לבדו אינו מוכיח מחסור בזיכרון.¹³

“האם המתנת הדיסק והפעולה משתפרות יחד כשסוגרים אפליקציות מיותרות?” שווה להשוות. לעומת זאת, כיבוי ה-page file כדי לבטל את הקריאות והכתיבות אינו מומלץ. זה מוריד את תקרת הזיכרון שאפשר לעשות לו commit ויכול להזמין כשלים ואי-יציבות אחרים.¹⁴

flowchart TB
    accTitle: איך לקרוא hard faults
    accDescr: hard fault קורא מהדיסק page שאינו בזיכרון; זה אינו מדד שקובע לבדו כשל פיזי או מחסור בזיכרון.
    A["ה-page הנחוץ אינו בזיכרון"] --> B["קריאה בחזרה מקובץ"]
    B --> C["מתרחש disk I/O"]
    C --> D["משווים שימוש בזיכרון ואת הפעולה"]
    B -.-> E["אינו אומר כשל פיזי"]

איור 11: לא קופצים לכשל או לבעיית page file לפי השם “hard fault” לבדו.

וגם, אם יש שגיאות קריאה/כתיבה, אזהרת אחסון קריטית, או ניתוקים פתאומיים, מגבים קודם את הנתונים החשובים, לפני התאמת services. גם לאזהרות אחסון של Windows, Microsoft מכוונת לגבות קודם. היעדר אזהרה גלויה לבדו אינו מבטיח שכל דיסק בריא.¹⁵

אחרי הגיבוי, בודקים את האבחון שספק המחשב או האחסון מספק, ואת מידע ה-driver וה-firmware לדגם הספציפי. לא שמים שינויי Registry גורפים ממאמרים ישנים לפני זה בלי לאשר את הדגם ואת התנאים שבהם הם חלים. למשל, אחת מבעיות הידועות של Microsoft שנוגעת ל-SysMain מוגבלת לתנאים ספציפיים ב-Windows 7. תאריך העדכון של המסמך לבדו אינו מספיק כדי לשפוט שהוא חל על Windows 11 הנוכחי.¹⁶

flowchart TB
    accTitle: סדרי עדיפויות כשיש אזהרת אחסון
    accDescr: כשיש אזהרה קריטית או שגיאות קריאה/כתיבה, נותנים עדיפות לגיבוי ולאבחון שמתאים לדגם על פני אופטימיזציית הגדרות.
    A["אזהרה או שגיאות קריאה/כתיבה"] --> B["מגבים נתונים חשובים"]
    B --> C["בודקים את האבחון של היצרן"]
    C --> D["מתקנים או נוקטים אמצעים לפי התנאים החלים"]

איור 12: כשיש סימנים לכשל, הגנה על הנתונים קודמת להורדת אחוז.

9. שופטים “תוקן” לפי העבודה המקורית, לא לפי האחוז

שופטים אם אמצעי עבד לפי הפעולה שהתקשיתם בה במקור. משווים תוצאות כמו “פתיחת אפליקציה כבר לא ממתינה”, “ההעתקה מסתיימת כרגיל”, ו”ההקלדה כבר לא נתקעת” מול לפני השינוי. גם אם תקופות הדיסק ב-100% מתקצרות, לא קוראים לזה גמור כל עוד תוצאות החיפוש כבר לא מתעדכנות או שההגנה נשארת עצורה.

להשוואה, מיישרים אותה פעולה, אותו יעד, ובמידת האפשר אותו מצב רקע. להשוואה זמנית כמו SysMain, בדיקה בסדר מצב מקורי → עצור → מצב מקורי מקלה להבחין באפשרות שהעבודה פשוט הסתיימה עם חלוף הזמן. ועדיין, כי להרצה השנייה יש הבדלים כמו cache חם, השוואה אחת אינה נחשבת הוכחה לסיבתיות.

זו גישת החקירה שהמאמר מציע. במקום לאסוף הגדרות שמורידות מספר, רישום איזה שינוי שיפר את הפעולה המקורית תוך שמירה על היכולות שצריכים שימושי גם כשהבעיה חוזרת.

flowchart TB
    accTitle: החלטה שהאמצעי הושלם
    accDescr: בנוסף לשיפור הפעולה המקורית, בודקים את מצב החיפוש, ההגנה וה-services לפני שמסיימים את האמצעי.
    A["מריצים שוב את הפעולה המקורית"] --> B["זמן ההמתנה השתפר?"]
    B --> C["החיפוש וההגנה נשמרו?"]
    C --> D["שינויים זמניים הוחזרו?"]
    D --> E["רושמים תנאים ותוצאות ומסיימים"]

איור 13: שופטים לפי האם העבודה והיכולות שצריכים כולן התאוששו, לא לפי מספר הדיסק.

סיכום

לדיסק ב-100% אין נוהל כל-יכול שעוצר יחד את SysMain, Windows Search ו-Defender. קודם בודקים את חלון הזמן, את הדיסק הרלוונטי, את הקבצים ואת זמן התגובה. על הבסיס הזה, נקודת ההתחלה היא להפריד: השוואה זמנית ל-SysMain רק כשצריך, בחינה מחדש של טווח החיפוש ל-Search, וניתוח עם הגנה דולקת ל-Defender.

אם אפליקציית Windows עסקית ממשיכה לסבול מבעיות כמו “רק פעולה מסוימת איטית” או “רק המחשבים ברצפת הייצור קופאים”, אפשר גם להביא אותן לייעוץ הטכני של KomuraSoft. זמן ההתרחשות, שלבי השחזור, סוגי הקבצים המעורבים, ורישומים מלפני ואחרי השינוי הופכים את נקודת הכניסה לחקירה למוחשית. כשמשתפים לוגים או הקלטות, בודקים שאין בהם מידע סודי.

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

למה השימוש בדיסק הוא 100% כשעוברים רק כמה MB/s?

כי זמן הפעילות של הדיסק ומספר הבתים שמועברים לשנייה הם מדדים נפרדים. קריאות וכתיבות קטנות וזמני המתנה ל-I/O משאירים את הדיסק עסוק גם כשנפח ההעברה קטן. בודקים את זמן התגובה של הדיסק הרלוונטי והאם הפעולות האיטיות מתרחשות באותו זמן.

כיבוי SysMain תמיד מאיץ את המחשב?

לא בהכרח. משאירים קודם את ההגדרות הרגילות, ורק כשעולה חשד לקשר ל-SysMain רושמים את המצב המקורי ואז משווים עצירה זמנית עם הפעלה מחדש. לא מחליטים על כיבוי קבוע על סמך ההשוואה הזו לבדה.

מותר לעצור את Windows Search?

זה משפיע על מהירות חיפושים שתלויים ב-index ועל עדכון התוצאות, ולכן זו לא הפעולה הראשונה. בודקים את התקדמות ה-indexing, ואם תיקיות שאינן נחוצות נכנסות לאינדקס, שוקלים קודם לצמצם את הטווח.

מותר לכבות את Defender כדי להוריד את השימוש בדיסק?

כיבוי real-time protection כהאצה יומיומית אינו מומלץ. משתמשים במנתח הביצועים של Microsoft Defender Antivirus כדי לתעד את עומס הסריקה ולברר אילו קבצים ותהליכים מעורבים. גם את הפריטים בראש הדוח לא מוסיפים כפי שהם להגדרות exclusion.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.