WPR/WPA בפועל — מבוא לחקירת "כל ה-PC איטי" על פני כל המערכת

“כל ה-PC האט אחרי שהתקינו אפליקציה, אבל Task Manager מראה עודף גם ב-CPU וגם בזיכרון.” “מחשב אחד לוקח 3 דקות להתחיל.” מה שמקשה בייעוצים האלה הוא שאפילו לא יודעים באיזה process להסתכל.

גם כשאפליקציה A היא האיטית, הסיבה יכולה להיות סריקת antivirus, כתיבות כבדות של service אחר, או שרשרת locks שחוצה כמה processes. מה שצריך הוא לרשום את פעילות כל ה-OS על ציר זמן אחד ולעקוב לאן הזמן הלך.

הכלים לזה הם Windows Performance Recorder (WPR) ו-Windows Performance Analyzer (WPA). WPR מצלם את הרישום באמצעות ETW (Event Tracing for Windows), ו-WPA קורא את הרישום בגרפים ובטבלאות. בודקים, לאורך ציר הזמן, אילו processes ו-stacks השתמשו ב-CPU, למה כל thread חיכה, ואיזה process הנפיק I/O דיסק לאיזה קובץ.

השאלה שהמאמר הזה עונה עליה היא “איך רושמים איטיות מערכתית, ואיזה מבין CPU, זמן המתנה ו-I/O בודקים?” מיועד לאנשי IT בעסקים קטנים ובינוניים ולמפתחי אפליקציות Windows, הוא מכסה מהפרקטיקה של הצילום עד הניתוח, מעוגן במקורות ראשוניים נכון לאוגוסט 2026. קוראים אותו עם ההבדל בין “ה-CPU גבוה” ל-“ה-CPU נמוך ועדיין איטי” כציר מנחה.

איך זה שונה מ-Process Monitor, שבודק גישה לקבצים ול-Registry, ומ-PerfView, שעוקב אחרי CPU ו-GC של אפליקציית .NET, מכוסה ב-פרק 2.

1. קודם כל, המסקנות

הזרימה הבסיסית היא “מצלמים ב-WPR → מצמצמים למרווח הבעיה ב-WPA → מבודדים CPU, המתנות או I/O.” גם בעיה ש-process יחיד אינו יכול להסביר אפשר לחקור במעקב אחרי כל process ואחרי ה-kernel על אותו ציר זמן.¹²

להפריד איפה מצלמים מאיפה קוראים

כלי הצילום wpr.exe מגיע עם Windows 8.1 ואילך, כך שאין צורך בהתקנה נוספת. גרסת ה-GUI, WPRUI, וכלי הניתוח WPA כלולים ב-Windows ADK. כי אפשר לפצל את העבודה ל“רק לצלם עם wpr.exe בסביבת הלקוח; לקרוא ב-WPA במחשב שלכם,” אפשר לצלם גם בשרת שאי אפשר להוסיף בו תוכנה.¹²

לבעיה שאפשר לשחזר, שלושת הצעדים הבסיסיים הם, עם הרשאות administrator, wpr -start GeneralProfile -filemode → לשחזר את הבעיה → wpr -stop C:\temp\trace.etl.³ מכינים את תיקיית היעד, מקבלים אישור לצילום, ומחליטים איך ה-ETL יטופל לפני שמריצים. המתנה לבעיה ובעיות בזמן boot דורשות שיטות צילום שונות, לכן ראו פרק 3 ו-פרק 8.

הגרף הראשון לפתוח ב-WPA

קודם מצמצמים למרווח הבעיה, ואז בוחרים את כיוון החקירה מהטבלה הבאה.⁴⁵

Sampled מראה את פירוק זמן ה-CPU מדגימות שנלקחות בערך כל מילישנייה.⁶ Precise עוקב אחרי המתנות מרישום מלא של context switches. מעקב אחרי הצד ששחרר המתנה, עם Waits → ReadyingProcess → ReadyThreadStack כרמזים, היא הטכניקה שהמאמר הכי רוצה להעביר.⁴⁷

איך לקרוא את המאמר הזה לפי מטרה

אם אתם אחראים על הצילום, מתחילים ב-פרק 2 וב-פרק 3; אם אתם קוראים ETL שכבר צולם, מתחילים ב-פרק 4. קריאת stacks לפי שם פונקציה דורשת הגדרת symbols, ולאפליקציה שלכם מוסיפים את הנתיב ל-PDBs שלה.⁸ כשחוקרים קוד JIT של .NET, גם CLR events בזמן הצילום נדרשים, לכן בודקים את הערות ה-.NET בפרק 4 לפני הצילום.

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

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

2. איפה הכלים יושבים — WPR מצלם, WPA קורא

Windows Performance Toolkit (WPT) הוא ערכת כלי חקירת הביצועים הכלולה ב-Windows ADK (Windows Assessment and Deployment Kit), והליבה שלה היא הזוג WPR ו-WPA.² התפקידים מחולקים בבירור.

WPR מצלם, WPA מנתח

• WPR (Windows Performance Recorder) = צילום. הוא אוגד ספקי ETW ליחידות שנקראות “profiles”, מתחיל ועוצר רישום, ומייצר קובץ ETL. גרסת command-line, wpr.exe, מגיעה עם Windows 8.1 ואילך, בלי התקנה נוספת. גרסת ה-GUI (WPRUI.exe) כלולה ב-ADK.¹
• WPA (Windows Performance Analyzer) = ניתוח. פותח קובץ ETL ומנתח אותו בגרפים ובטבלאות. נדרשת התקנת ADK.²

במילים אחרות, אם כל מה שעושים הוא לצלם משורת הפקודה, אין צורך להתקין תוכנה נוספת בסביבת הלקוח. מצלמים עם wpr.exe הסטנדרטי של ה-OS, לוקחים את קובץ ה-ETL הביתה, וקוראים אותו ב-WPA במחשב שלכם — אותו פיצול כמו “מצלמים ב-pktmon, קוראים ב-Wireshark” ב-packet capture.

flowchart LR
    accTitle: הפיצול של צילום ב-WPR וקריאה ב-WPA
    accDescr: בסביבת הלקוח רושמים עם wpr.exe הסטנדרטי של ה-OS ומייצרים קובץ ETL, לוקחים הביתה ומנתחים ב-WPA שמותקן דרך ADK במחשב שלכם
    subgraph customer["סביבת הלקוח (בלי התקנה נוספת)"]
        wpr["wpr -start → שחזור הבעיה → wpr -stop"] --> etl["קובץ ETL"]
    end
    subgraph office["המחשב שלכם (WPA מותקן דרך ADK)"]
        wpa["ניתוח גרפים וטבלאות ב-WPA"]
    end
    etl -->|"לוקחים הביתה"| wpa

בחירה בין Procmon, PerfView ו-WPR/WPA

קודם נמיין גם במה זה שונה מכלים דומים.

אם Procmon הוא יומן הפעולות של “מה הוא עשה” ו-PerfView הוא “מה קרה בתוך .NET,” WPA הוא הכלי שבודק “לאן הלך הזמן” על פני כל process.

כשרוצים לרשום גם את ה-events של האפליקציה שלכם

איך ETW עצמו עובד ואיך מכניסים את האפליקציה שלכם ל-ETW מכוסים ב”מבוא ל-Windows Event Log ו-ETW.” אם האפליקציה שלכם פולטת ETW events, אבני הדרך שלה נרשמות באותו trace, מה שמקל מאוד על המתאם.

שימו לב, עם זאת, שWPR רושם רק את ה-events של הספקים שה-recording profile שבחרתם מפעיל. GeneralProfile אינו כולל את הספק שלכם. כדי לרשום אותם יחד, מכינים recording profile מותאם (.wprp) שמפעיל את הספק שלכם ומשלבים אותו כמו ב-wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, עם שם ה-profile שבתוך קובץ ה-.wprp אחרי !³.

3. צילום בפועל (WPR) — start, שחזור, stop

מה להחליט לפני שמריצים

בסביבת ייצור, אל תניחו שגם צילום קצר בטוח ללא תנאי. ETW קל, אבל רישום נפח גדול של events עם stacks צורך כמות מסוימת של CPU וזיכרון. בוחרים זמן עם מעט השפעה עסקית, ומעבירים אותו באותו תהליך אישור כמו כל שינוי רגיל.

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

הבא הוא דוגמה לצילום בעיה שאפשר לשחזר במקום ב-File mode. לבעיה שתזמונה לא ידוע, הולכים ל-Memory mode ב-סעיף 3.1; לבעיות בזמן boot או logon, הולכים ל-פרק 8.

צילום רגיל הוא “start → שחזור → stop”

מריצים אלה ב-Command Prompt שנפתח כ-administrator. -profiles מציג מראש את ה-profiles הזמינים, ו--status בודק את המצב בזמן הצילום. ה--cancel בסוף משמש רק לביטול באמצע ולזריקה; הוא אינו חלק מנוהל השמירה הרגיל.

:: רשימת ה-profiles המובנים שניתן להשתמש בהם
wpr -profiles

:: 1. התחלת הצילום (profile כללי, file mode)
wpr -start GeneralProfile -filemode

:: 2. משחזרים את התופעה (בדיקת מצב הצילום: wpr -status)

:: 3. עוצרים ושומרים (אפשר לצרף תיאור של הבעיה).
::    יוצרים מראש את תיקיית היעד (בלי זה, -stop נכשל בשמירה)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "שחזור של האטת כל ה-PC בזמן ש-App X עולה"

:: כדי לבטל באמצע, זורקים בלי לשמור
wpr -cancel

לבחור מה לרשום עם profile

מה שמעבירים ל--start הוא profile, חבילה של ספקי ETW שחקירה צריכה.³ לזכור רק את אלה שבשימוש תכוף מספיק.⁹

אפשר לציין כמה profiles בבת אחת בחזרה על -start (למשל wpr -start GeneralProfile -start FileIO -filemode).³

flowchart TB
    accTitle: זרימת צילום WPR ואיך בוחרים mode
    accDescr: בעיה שאפשר לשחזר במקום מצולמת בקצרה ובאמינות ב-file mode; בעיה שתזמונה לא ידוע ממתינים לה ב-ring buffer של memory mode כברירת מחדל. בעיה בזמן boot או logon משתמשת ב-boot trace. בכל מקרה נוהל start, שחזור, stop זהה
    q{"מתי הבעיה מתרחשת?"}
    q -->|"ניתנת לשחזור במקום"| file["צילום קצר ואמין עם -filemode"]
    q -->|"תזמון לא ידוע"| mem["המתנה ב-Memory mode (ברירת מחדל, ring buffer) (סעיף 3.1)"]
    q -->|"בזמן boot או logon"| boot["Boot trace (פרק 8)"]
    file --> s1["wpr -start → שחזור או המתנה לבעיה → wpr -stop"]
    mem --> s1

3.1. Memory mode ו-File mode — אפשר לשחזר, או ממתינים?

ל-WPR יש שני מצבי יעד רישום, והברירת מחדל היא Memory mode (מאגר מעגלי בזיכרון).

Memory mode הוא להמתנה שבעיה תתרחש. כי זה ring buffer שדורס קודם את ה-events הישנים ביותר, הוא מתאים להשארת הצילום רץ בזמן שממתינים לבעיה שתזמונה לא ידוע, ולעצירה ברגע שהיא קורה.

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

flowchart LR
    accTitle: איך Memory mode ו-File mode רושמים
    accDescr: Memory mode רושם למאגר מעגלי בזיכרון שבו ה-events הישנים ביותר נדרסים ורק האחרונים נשארים, ולכן מתאים להמתנה לבעיה. File mode שומר הכול בקובץ, אבל התקרה היחידה היא שטח דיסק פנוי, ולכן מתאים לשחזור קצר ואמין
    ev["זרם ETW events"] --> ring["Memory mode: מאגר מעגלי (הישנים נדרסים קודם → רק האחרונים נשארים)"]
    ev --> filem["File mode: הכול נשמר בקובץ (התקרה היא שטח דיסק פנוי)"]
    ring -.-> use1["מתאים להמתנה לבעיה שתזמונה לא ידוע"]
    filem -.-> use2["מתאים לבעיה שאפשר לשחזר באמינות בזמן קצר"]

כלל האצבע לבחירה הוא כדלקמן.

• ניתן לשחזור במקום → File mode. מתחילים ממש לפני השחזור, עוצרים ממש אחרי, ומשאירים את הצילום בתוך כמה דקות
• תזמון לא ידוע → ממתינים ב-Memory mode (ברירת המחדל). ברגע שזה קורה, מריצים wpr -stop
• גם כמה דקות של GeneralProfile יכולות לייצר ETL בטווח מאות MB עד GB. קובץ גדול מדי עלול להיות בלתי-ניתן-לניתוח ב-WPA, כך ש”ככל שהצילום ארוך יותר, כך טוב יותר” מזיק¹⁰¹¹

צילום מה-GUI

כדי לצלם מה-GUI, מפעילים WPRUI, בוחרים profile ו-Logging mode, ולוחצים Start ואז Save. פרטי הנוהל בנושאי How-to הרשמיים.¹¹ כשמבקשים מאיש קשר באתר הלקוח לצלם, אפשר גם לכתוב מסמך נוהל שממוקד בצעדי start, שחזור ו-stop, עם התנאים המוקדמים ופעולת הביטול בנפרד.

4. יסודות קריאת WPA — גרפים, כלל הזהב של טבלאות, וצמצום טווח הזמן

כשפותחים את ה-ETL שצולם ב-WPA, Graph Explorer משמאל מציג תמונות ממוזערות של גרפים בקטגוריות כמו System Activity, Computation, Storage ו-Memory.¹² גוררים את הגרף הרצוי ללשונית Analysis מימין, והגרף מופיע למעלה עם טבלה מתחתיו.

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

4.1. סדר העמודות קובע איך הנתונים מצטברים

לטבלת WPA יש שני פסים אנכיים, אחד זהוב ואחד כחול: העמודות משמאל לפס הזהוב מרובדות (מקבצות) את הנתונים בסדר הזה, והעמודות מימין לפס הכחול הן ערכי צבירה.¹³

סידור “Process → Stack” נותן צבירת stack לפי process; “Stack → Process” נותן צבירה על פני כל process שמשתמש באותו stack. גרירת עמודות לשינוי הסדר היא עצמה פעולת הניתוח. ברגע שמבינים את הנקודה הזו, כל טבלת WPA נקראת באותו אופן.

flowchart LR
    accTitle: כלל הזהב של טבלאות — שני הפסים ותפקידי העמודות
    accDescr: סדר העמודות משמאל לפס הזהוב מרובד את הנתונים, העמודות בין הפס הזהוב לכחול הן עמודות תצוגה, והעמודות מימין לפס הכחול הן ערכי צבירה. גרירת עמודות לשינוי הסדר היא עצמה פעולת הניתוח
    left["משמאל לפס הזהוב: עמודות קיבוץ (סדר = היררכיה)"] --> gold["פס זהוב"]
    gold --> mid["בין הפסים: עמודות תצוגה"]
    mid --> blue["פס כחול"]
    blue --> right["מימין לפס הכחול: ערכי צבירה (Sum, % וכן הלאה)"]
    left -.-> op["גרירת עמודה = פעולת ניתוח (Process → Stack נותן צבירת stack לפי process)"]

4.2. לצמצם למרווח שבו הבעיה התרחשה

גוררים על הגרף כדי לבחור טווח, ואז לוחצים לחיצה ימנית ובוחרים “Zoom,” והצבירה עוברת רק למרווח הזה. עיקרון חקירת ביצועים הוא תמיד להסתכל רק על “המרווח שבו הבעיה התרחשה” (פרק 9).

4.3. לטעון symbols ולראות stacks לפי שם פונקציה

כדי לקרוא stacks לפי שם פונקציה, מריצים Trace > Load Symbols מהתפריט.¹⁴ כברירת מחדל הוא מפנה לשרת ה-symbols הציבורי של Microsoft (msdl.microsoft.com), כך ש-stacks ב-Windows עצמו נפתרים כל עוד יש חיבור לאינטרנט.

כדי לראות גם שמות פונקציות באפליקציה שלכם, מוסיפים את התיקייה שמכילה את ה-PDBs של האפליקציה ב-Trace > Configure Symbol Paths.⁸ מהו PDB, ולמה תמיד כדאי לשמור אחד גם ל-release builds, מסוכם ב”מהו PDB (Program Database)?”.

ל-.NET, מטפלים ב-NGen images ובקוד JIT בנפרד

ל-NGen native images של .NET Framework, WPR מייצר NGen PDBs (.ngenpdb) בזמן הצילום, שם אותם בתיקייה ליד ה-trace, ו-WPA מפנה אליהם אוטומטית.⁸ המנגנון הזה ספציפי ל-NGen images; הקוד שלכם באפליקציית .NET רגילה שרצה תחת JIT אינו מכוסה.

המיפוי מכתובות קוד JIT לשמות פונקציות נפתר מ-JIT events שה-CLR פולט. לכן כשחוקרים אפליקציית .NET, מכינים recording profile (.wprp) שמפעיל את ספקי ה-CLR (Microsoft-Windows-DotNETRuntime ואת ה-Rundown שלו), ומשלבים אותו בצורה wpr -start GeneralProfile -start MyDotNet.wprp!ProfileName, בדיוק כמו עם הספק שלכם בפרק 2, כך ש-CLR events נכללים ב-trace (אפשר לבדוק אילו built-in profiles ה-WPR המקומי מציע עם wpr -profiles).

מעל זה, שומרים את ה-PDBs שנוצרים ב-build למיפוי לשורות מקור, ומוסיפים אותם ל-symbol path שתואר למעלה.

flowchart TB
    accTitle: פתרון symbols לקריאת stacks לפי שם פונקציה
    accDescr: כשמריצים Trace Load Symbols, Windows עצמו נפתר משרת ה-symbols הציבורי של Microsoft והאפליקציה שלכם מ-PDBs של ה-build שנוספו ל-symbol path. NGen images נפתרים מ-NGen PDBs ש-WPR מייצר, וקוד JIT של .NET מ-CLR JIT events ב-trace פלוס PDBs של ה-build
    load["Trace > Load Symbols"] --> ms["Windows עצמו: שרת symbols ציבורי (msdl)"]
    load --> own["האפליקציה שלכם: PDBs של ה-build שנוספו ב-Configure Symbol Paths"]
    load --> ngen["NGen images של .NET Framework: .ngenpdb ש-WPR מייצר"]
    load --> jit["קוד JIT של .NET: CLR JIT events ב-trace + PDBs של ה-build"]

4.4. להחליט אם לחקור CPU, המתנות או I/O

אחרי שהוגדר, מסתכלים על האם ה-CPU היה גבוה או נמוך במרווח הבעיה. אם גבוה, הולכים ל-Sampled בפרק 5. אם נמוך, קודם בודקים אם ליבה או thread מסוימים תקועים; אם לא, עוקבים אחרי ההמתנות עם Precise בפרק 6. אם הדיסק חשוד, הולכים ל-פרק 7.

flowchart TB
    accTitle: בחירת גרף WPA מהתסמין
    accDescr: Zoom למרווח הבעיה; אם ה-CPU גבוה הולכים ל-CPU Usage Sampled; אם נמוך ועדיין איטי, בודקים ליבה תקועה ואז ניתוח המתנות ב-CPU Usage Precise; אם הדיסק חשוד הולכים ל-Disk Usage ו-File IO
    zoom["Zoom למרווח הבעיה"] --> cpu{"CPU באותו מרווח?"}
    cpu -->|"גבוה"| sampled["פרק 5: CPU Usage (Sampled) ל-'מי שורף CPU באיזו פונקציה'"]
    cpu -->|"נמוך ועדיין איטי"| core{"ליבה אחת או thread אחד תקוע?"}
    core -->|"כן"| sampled
    core -->|"לא"| precise["פרק 6: CPU Usage (Precise) ל-'למה הוא חיכה'"]
    cpu -->|"דיסק חשוד"| disk["פרק 7: Disk Usage / File I/O לזיהוי האשם"]

5. כשה-CPU גבוה — “מי שורף CPU באיזו פונקציה” עם CPU Usage (Sampled)

מה שהפרק הזה מחפש הוא נתיב הקריאה שמשתמש בנתח גדול של זמן CPU.

אם ה-CPU תקוע, במה שמסתכלים הוא CPU Usage (Sampled). אלה נתוני דגימה שרושמים, בערך כל מילישנייה על כל CPU, “איזה stack של process רץ עכשיו,” ויחס ספירות הדגימה הוא ישירות פירוק זמן ה-CPU.⁶

flowchart LR
    accTitle: איך CPU Usage Sampled עובד
    accDescr: בערך כל מילישנייה נרשם ה-stack שרץ על כל CPU, ויחס הדגימות המצטברות הוא פירוק זמן ה-CPU. קוראים מ-process ל-thread, ל-stack ולפונקציה. פעילות קצרה שמסתיימת בין דגימות אינה נלכדת
    tick["Interrupt בערך כל 1 ms"] --> snap["רישום ה-'stack שרץ עכשיו' על כל CPU"]
    snap --> agg["צבירת הדגימות (יחס = פירוק זמן CPU)"]
    agg --> drill["Drill down Process → Thread → Stack → פונקציה"]
    snap -.-> miss["פעילות קצרה שמסתיימת בין דגימות אינה נלכדת"]

Drill down מ-process ל-stack לפונקציה

1. מ-Computation ב-Graph Explorer, שמים CPU Usage (Sampled) בלשונית Analysis ובוחרים את ה-preset Utilization by Process, Stack.⁵
2. מסתכלים על ה-processes בסדר יורד של Weight (או Count). מה שהיה “50%” ב-Task Manager מזוהה קודם ברמת ה-process.
3. מרחיבים את עמודת Stack של process האשם. Stacks מצטברים כעץ, וירידה לאורך הנתיב שבו המספרים לא יורדים הרבה בכל פיצול מביאה לפונקציה ששורפת CPU. אם symbols נפתרו, זה קו ישר לפונקציה המדויקת בקוד שלכם.
4. אם הרחבת העץ מייגעת, מחליפים את תצוגת הגרף ל-Flame (flame graph). הרוחב מצויר כנתח זמן ה-CPU, כך שאיזה נתיב קריאה שולט ברור במבט. ל-CPU Usage (Sampled) יש גם preset Flame by Process, Stack.¹³

Sampled אינו יכול למדוד את משך הריצה המדויק של הרצה אחת

כי זו דגימה, פעילות קצרה שמסתיימת בין דגימות אינה נלכדת.⁶ זוכרים שזה כלי לראות “איפה CPU היה בשימוש בסך הכול,” לא כלי למדוד את זמן הריצה המדויק של כל הרצה בודדת.

6. כשה-CPU נמוך ועדיין איטי — CPU Usage (Precise) וניתוח המתנות

6.1. לפני ניתוח המתנות, בודקים ליבה אחת תקועה

“שימוש CPU כולל נמוך” אינו אומר “ה-CPU אינו צוואר הבקבוק.” במחשב עם 16 ליבות, עבודה טורית שתקועה לליבה אחת (UI thread יחיד שרץ במלוא העוצמה) מופיעה ככ-6% בלבד בסך הכול.

קודם בודקים, עם Sampled מפרק 5 או עם Utilization by CPU ב-CPU Usage (Precise), אם ליבה או thread מסוימים תקועים. אם גם כלום לא תקוע, מניחים שהעבודה אינה נכשלת בשימוש ב-CPU אלא מחכה למשהו, ועוברים לניתוח המתנות. מכאן ואילך, הכלי הוא CPU Usage (Precise).

6.2. להפריד “זמן שהושקע בהמתנה” מ”המתנה ל-CPU אחרי התעוררות”

איפה ש-Sampled הוא דגימה, Precise הוא רישום מלא של context switches (החלפות thread). Thread נכנס להמתנה, מישהו מעיר אותו (Ready), והוא עולה על CPU — כל סיבוב כזה נשמר כשורה אחת, ואפשר לקרוא את העמודות הבאות.⁷⁴

flowchart LR
    accTitle: סיבוב המתנה אחד והעמודות המתאימות
    accDescr: Thread נכנס להמתנה על ה-stack שנשמר ב-NewThreadStack וממתין לזמן Waits. כשמישהו מעיר אותו, הצד הזה נשמר ב-ReadyingProcess וב-ReadyThreadStack, וה-thread ממתין את זמן Ready לתחרות CPU לפני שהוא רץ שוב
    run1["רץ"] -->|"נכנס להמתנה (נשמר ב-NewThreadStack)"| waitst["ממתין (Waits (us))"]
    waitst -->|"מישהו מעיר אותו (ReadyingProcess / ReadyThreadStack)"| ready["Ready (ממתין לתחרות CPU)"]
    ready -->|"עולה על CPU"| run2["רץ שוב"]

6.3. מה-thread המעוכב, לעקוב אחרי כל מעיר לפי התור

סדר הקריאה הוא כדלקמן.⁴

1. להגדיר את הגרף ואת העמודות

מחילים את ה-preset Utilization by Process, Thread ומוסיפים NewThreadStack ו-ReadyThreadStack לעמודות.

2. לבחור את ה-thread של הפעולה המעוכבת

קודם מזהים את ה-thread שהריץ את הפעולה המעוכבת, כמו ה-UI thread או ה-thread שמטפל בבקשה הנוגעת בדבר. אם מסתכלים רק בסדר יורד של סך Waits, threads בריאים שממתינים במכוון, כמו message pump או timer, יוצאים למעלה.

אם CPU Usage (ms) של ה-thread היעד גדול, זו בעיית CPU מפרק 5; אם Waits שולטים, זו בעיית המתנה.

3. לראות “מה הוא עשה כשעצר” ב-NewThreadStack

מרחיבים NewThreadStack. WaitForSingleObject או EnterCriticalSection פירושם המתנת lock; בתוך I/O סינכרוני כמו ReadFile, המתנת I/O; בתוך קבלת socket, המתנה שהצד השני יגיב.

4. לראות “מי שחרר את ההמתנה” ב-ReadyThreadStack

מרחיבים ReadyThreadStack ובודקים ReadyingProcess / ReadyingThreadId. אם הוא התעורר מ-KiTimerExpiration של ה-kernel, זה היה timer (הוא ישן עד ה-timeout); אם הוא התעורר מעיבוד השלמת I/O, זה מאשר שהייתה המתנת I/O.⁴

5. לחזור על אותה חקירה על המעיר

אם המעיר הוא thread אחר או process אחר, חוקרים את ה-thread הזה אחר כך באותו נוהל.

למשל, שרשרת כמו A חיכה ש-B ישחרר lock, B חיכה לתגובת RPC מ-C, ו-C חיכה ל-I/O דיסק. מעקב אחרי השרשרת הזו עד השורש נותן את ה-critical path של העיכוב.⁷

flowchart LR
    accTitle: שרשרת ה-critical path שמעקב אחריה בניתוח המתנות
    accDescr: רואים ב-NewThreadStack של thread A המעוכב מה הוא עשה כשעצר, מזהים את המעיר B מ-ReadyThreadStack ומ-ReadyingProcess, חוקרים את B באותו נוהל, ויורדים עד I/O הדיסק בשורש
    a["Thread A (הפעולה המעוכבת)"] -->|"NewThreadStack: עצר בהמתנת lock"| b["Thread B (מחזיק את ה-lock)"]
    b -->|"NewThreadStack: ממתין לתגובת RPC"| c["Process C"]
    c -->|"NewThreadStack: ממתין ל-I/O סינכרוני"| d["I/O דיסק (השורש)"]
    d -.->|"השלמה מעירה את C"| c
    c -.->|"התגובה מעירה את B"| b
    b -.->|"שחרור ה-lock מעיר את A (מופיע ב-ReadyThreadStack)"| a

להפוך את סיבת ההמתנה לסקירת תכנון

בפרויקט שבו “עשינו multithreaded אבל זה לא נהיה מהיר יותר,” למשל, הנוהל הזה מראה כל worker עומד בתור מאחורי lock יחיד בדיוק כמו שהוא. הימנעות מתחרות על locks בתכנון נדונה ב”שיטות עבודה מומלצות ל-multithreading בפועל: מהדורת .NET,” והמנגנון של Windows שרץ על הודעות השלמה במקום להמתין ב-I/O סינכרוני ב”I/O Completion Ports (IOCP) ו-thread pool של .NET.” נעיצת “למי הוא חיכה” ב-WPA ואז תיקון עם עקרונות התכנון האלה הם זרימה אחת רציפה.

7. דיסק ו-file I/O — זיהוי “מישהו סורק את הדיסק”

האשם הקלאסי מאחורי “כל ה-PC איטי” אינו ה-CPU אלא הדיסק. חוקרים עם Disk Usage ו-File I/O בקטגוריית Storage.¹⁵

7.1. להפריד “עיבוד מכשיר” מ”עמידה בתור” ב-Disk Usage

Disk Usage הוא הרישום של I/O דיסק. מתחילים בהבחנה בין שתי העמודות הבאות.⁶

IO Time תמיד לפחות Service Time, וההפרש הוא הזמן שהושקע בתור. אם IO Time ארוך בהרבה מ-Service Time, ה-I/O הזה חיכה בתור.⁶

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

7.2. איזה process הנפיק I/O לאיזה קובץ

לכן, עם ה-preset Utilization by Process, Path Name, Stack, מסתכלים איזה process הנפיק I/O לאיזה קובץ מאיזה stack, בסדר יורד של IO Time או Size.¹⁵ שתי התשובות שעולות הכי הרבה בשטח הן אלה.

• תוכנת antivirus סרקה כל קובץ. זה מופיע כ-process של האנטי-וירוס שמנפיק נפח גדול של קריאות במרווח שבו האפליקציה הייתה איטית להתחיל. שם ה-process, הנתיב והנפח הם ראיות מוכנות לשימוש בדיון על הגדרות החרגה.
• Process אחר כתב בכבדות. Backup, indexer, logging מוגזם וכן הלאה. מתי כתיבה מגיעה לדיסק כרוך ב-cache manager, כך שהעובדה ש”רגע הכתיבה” ו”רגע שהדיסק עסוק” יכולים להתפצל מוסברת גם ב”Cache Manager — מתי WriteFile באמת מגיע לדיסק?.”

7.3. לראות איטיות לפני הדיסק עם File I/O

File I/O הוא שכבה אחת למעלה: הרישום של פעולות קבצים שהאפליקציה הנפיקה (Create, Read, Write וכן הלאה), ו-presets כמו Duration by Process, Thread, Type צוברים זמן לפי שם קובץ ולפי פעולה.¹⁵

מקרה שבו הזמן מושקע במערכת הקבצים או ב-filter driver לפני ההגעה לדיסק אינו מופיע ב-Disk Usage, כך שהפער עצמו, “Disk Usage שקט אבל File I/O איטי,” הוא רמז. אם רוצים להתחיל מאיך I/O סינכרוני ואסינכרוני עובדים, ראו “I/O סינכרוני ואסינכרוני — מה OVERLAPPED באמת אומר.”

flowchart TB
    accTitle: השכבות השונות ש-File IO ו-Disk Usage רואים
    accDescr: פעולת קובץ של אפליקציה עוברת דרך מערכת הקבצים ו-filter drivers ומגיעה למכשיר הדיסק מתור I/O של ה-OS. File IO רושם את הפעולות בשכבה העליונה, Disk Usage רושם את ה-IO שהגיע לדיסק, וההפרש בין IO Time ל-Disk Service Time מראה את הזמן בתור
    app["אפליקציה: ReadFile / WriteFile"] --> fio["מערכת קבצים ו-filter drivers (השכבה ש-File I/O רואה)"]
    fio --> queue["תור I/O של ה-OS"]
    queue --> dev["מכשיר דיסק (השכבה ש-Disk Usage רואה)"]
    fio -.-> n1["זמן שמושקע כאן אינו מופיע ב-Disk Usage"]
    queue -.-> n2["IO Time − Disk Service Time = זמן בתור"]
    dev -.-> n3["Disk Service Time = זמן עיבוד המכשיר"]

7.4. כשחושדים במחסור בזיכרון, בודקים גם זיכרון פיזי

קו החשיבה “אולי חסר זיכרון ויש swapping” יכול לקבל מיון ראשון ב-Task Manager וב-Resource Monitor לפני שעוברים ל-WPA.

אל תשללו מחסור בזיכרון בהסתכלות על committed memory לבדה. גם עם עודף ב-commit, לחץ זיכרון פיזי יכול לקצץ working sets ולהמשיך hard faults. בודקים גם זיכרון פיזי זמין ו-“Hard Faults/sec” ב-Resource Monitor. לאיך לקרוא אותם, ראו את המאמר מה באמת אומר Memory Usage ב-Windows?.

8. Boot ו-logon איטיים — הכניסה ל-boot tracing

עם סוג “ה-boot לוקח 3 דקות”, הבעיה נגמרת לפני שאפשר להריץ wpr -start ידנית. ל-WPR יש boot trace, שאפשר להגדיר כך שה-OS יתחיל לרשום אוטומטית ב-boot הבא.³

להגדיר רישום ל-boot הבא, ואז לשמור אחרי ה-restart

כמו בפרק 3, מחליטים על אישור הצילום וטיפול ב-ETL, ואז פועלים מ-Command Prompt שנפתח כ-administrator.

:: 1. מגדירים רישום אוטומטי ב-boot הבא
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (משחזרים boot איטי)

:: 3. אחרי boot, עוצרים את הרישום ושומרים (גם מנקים את ההגדרה)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "boot שלוקח 3 דקות"

flowchart LR
    accTitle: זרימת boot trace
    accDescr: מגדירים רישום אוטומטי ב-boot הבא עם addboot, ואז restart; ה-OS מתחיל לרשום אוטומטית ב-boot. שמירה עם stopboot אחרי logon גם מנקה את ההגדרה. כדי לנטוש, מנקים עם cancelboot
    add["הגדרה עם wpr -boottrace -addboot"] --> rebootpc["Restart (שחזור boot איטי)"]
    rebootpc --> auto["ה-OS מתחיל לרשום אוטומטית ב-boot"]
    auto --> stop2["שמירה עם -stopboot אחרי logon (גם מנקה את ההגדרה)"]
    add -.-> cancel["כדי לנטוש, -cancelboot"]

אחרי הצילום, אותו מיון “CPU, המתנה או I/O”

מדידת boot ו-shutdown ש-xbootmgr טיפל בה פעם אפשר גם להריץ ב-WPR הנוכחי עם אפשרויות כמו -onoffscenario Boot.³

ה-trace שצולם נקרא עם אותה ערכה כמו בפרקים הקודמים. מסתכלים איזה process נוצר מתי, בסדר כרונולוגי, בגרף Processes; עושים zoom למרווח שבו ה-boot תקוע; ומסווגים כ-CPU, המתנה או דיסק. דפוסים כמו אפליקציות startup שממתינות למשהו בטור, או התחלת service שנתקעה על I/O מסוים, נכנסים לתמונה.

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

9. דפוס העבודה — לסווג, zoom, stack, לחזור

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

מנעיצת הזמן עד אימות ההשערה

1. לנעוץ את זמן התופעה. לא “זה היה איטי” אלא “זה היה איטי מ-10:23:40 עד 10:24:10.” לוגים של האפליקציה, ה-event log, הערה ממי שהפעיל — כל דבר יעבוד. אם האפליקציה שלכם כותבת אבני דרך ל-ETW או ל-event log, ה-events בתוך ה-trace משמשים ישירות כסמני זמן.
2. Zoom רק למרווח הזה. צבירה על פני כל ה-trace מוחלקת לממוצעים, והחריגה שחשובה מתדלדלת. ניתוח WPA הוא תמיד השוואה של “המרווח שהיה חריג” מול “המרווח שהיה רגיל.”
3. לסווג “CPU, המתנה או I/O” קודם. מסתכלים על CPU Usage (Sampled); אם בוער, הולכים לפרק 5. אם לא בוער, הולכים ל-Waits ב-CPU Usage (Precise) (פרק 6). אם IO Time ב-Disk Usage מנופח, הולכים לפרק 7. מעבר קודם דרך הפיצול התלת-כיווני הזה מונע מכם ללכת לאיבוד.
4. לחזור על השערה → zoom → stack. אם חושבים “antivirus?”, מצמצמים ל-process הזה ומאשרים עם ה-stack. אם זה לא מחזיק, עוברים להשערה הבאה. לא להסיק מסקנה לפני שירדתם ל-stack ואישרתם היא המשמעת של חקירה מהסוג הזה.

flowchart LR
    accTitle: הלולאה האיטרטיבית של חקירת ביצועים
    accDescr: נועצים את זמן התופעה, עושים zoom למרווח, מסווגים CPU, המתנה או IO, מגבשים השערה ומצמצמים, ומאשרים עם ה-stack. אם מחזיק הסיבה מאושרת; אם לא, חוזרים עם ההשערה הבאה
    time["נעיצת זמן התופעה"] --> zoomstep["Zoom למרווח הזה"]
    zoomstep --> triage["סיווג CPU, המתנה או I/O"]
    triage --> hypo["גיבוש השערה וצמצום"]
    hypo --> stack["אישור עם ה-stack"]
    stack -->|"אושר"| fix["הסיבה זוהתה → מתקנים"]
    stack -->|"לא החזיק"| hypo

להחליט איך לטפל ב-ETL לפני הצילום

קובץ ETL לוכד מבט רחב על פנים המערכת: שמות כל ה-processes, נתיבי הקבצים שנפתחו, המודולים שנטענו, ו(תלוי ב-profile) שמות מפתחות Registry.

צילום GeneralProfile סטנדרטי אינו כולל גופי נתונים כמו תוכן תקשורת, אבל אם הפעלתם ספק מותאם, ה-payload של ה-events שלו (כמו מחרוזות שהאפליקציה רשמה) נכנס כמו שהוא.

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

flowchart LR
    accTitle: מה קובץ ETL לוכד ואיך לטפל בו
    accDescr: ETL לוכד כל שם process, נתיבי קבצים שנפתחו, מודולים, ותלוי ב-profile שמות מפתחות Registry; הפעלת ספק מותאם מוסיפה גם את ה-payload שלו. מתייחסים אליו כסודי, ובונים צילום מינימלי, הסכמה עם המקבל, ותקופת שמירה ומחיקה לנוהל
    etl["קובץ ETL"] --> a1["כל שמות ה-processes, נתיבי קבצים, מודולים"]
    etl --> a2["(תלוי ב-profile) שמות מפתחות Registry"]
    etl --> a3["payloads של ספק מותאם (מחרוזות שהאפליקציה רשמה)"]
    a1 -.-> rule["מתייחסים כסודי: צילום מינימלי, הסכמה עם המקבל, תקופת שמירה ומחיקה"]
    a2 -.-> rule
    a3 -.-> rule

10. סיכום

חקירת WPR/WPA אפשר לארגן לשלושת השלבים הבאים.

1. לצלם את המרווח שצריך. מצלמים עם wpr.exe, שמגיע עם Windows 8.1 ואילך, וקוראים את ה-ETL ב-WPA במחשב שלכם. הבסיס הוא wpr -start GeneralProfile -filemode → שחזור → wpr -stop trace.etl. אם אפשר לשחזר, File mode בתוך כמה דקות; אם ממתינים, Memory mode. לאיטיות בזמן boot, משתמשים ב-wpr -boottrace. ארוך יותר אינו טוב יותר, והמידע הפנימי ב-ETL מטופל כסודי.
2. לצמצם את טווח הזמן ולבחור את כיוון החקירה. ב-WPA, משמאל לפס הזהוב זה קיבוץ ומימין לפס הכחול זה ערכי צבירה. שולטים בסדר עמודות, ב-zoom למרווח ובהגדרת symbols, ואז מבודדים CPU, המתנות או I/O. מספקים PDBs לאפליקציה שלכם, ולקוד JIT של .NET בודקים גם את CLR events בזמן הצילום.
3. לעקוב עד ה-stack ולאמת את ההשערה. אם ה-CPU גבוה, יורדים מ-process לפונקציה ב-Sampled. גם אם ה-CPU הכולל נמוך, קודם בודקים ליבה או thread אחד תקוע, ואם אין, עוקבים אחרי ההמתנות ב-Precise. לדיסק, לא מחליטים את הסיבה מהפרש הזמן לבדו; מסתכלים על תגובת המכשיר ועל פירוק מי הנפיק את ה-I/O.

מה שעוקבים אחריו בניתוח המתנות הוא NewThreadStack (מה הוא עשה כשעצר) → Waits (כמה המתין) → ReadyingProcess ו-ReadyThreadStack (מי העיר אותו). חוקרים את המעיר באותו אופן, ואפשר לעקוב אחרי שרשרת העיכובים עד השורש.

WPA עלול להציף בהתחלה בכמות המידע על המסך. ועדיין, ברגע שמחזיקים ב“סדר עמודות הוא איך נתונים מצטברים” ו-“Sampled הוא איפה CPU היה בשימוש, Precise הוא למי הוא חיכה,” השאר הוא חזרה על נעיצת הזמן, zoom, סיווג ובדיקת ה-stack. בפעם הבאה שייעוץ מגיע שאומר “יש עודף CPU ועדיין איטי,” מצלמים trace בסדר הזה וקוראים אותו.

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

• נעיצת “איטי” עם PerfView ו-dotnet-trace — מבוא מעשי לחקירת ביצועי .NET
• מדריך מעשי ל-Process Monitor (ProcMon) — נעיצת “הגדרות לא הוחלו” ו-“ACCESS DENIED” בעשר דקות
• מבוא ל-Windows Event Log ו-ETW — להעלות את הלוגים של האפליקציה העסקית על מנגנוני ה-OS הסטנדרטיים
• מה באמת אומר Memory Usage ב-Windows — איך לקרוא Working Set, Private Bytes, Commit ו-pagefile
• Processor scheduling ב-Windows — Background services וליבות P/E
• מהו PDB (Program Database)? — הבנת מידע debug, symbols ו-Source Link

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בחקירות של בעיות ביצועים מערכתיות כמו “כל ה-PC האט ואי אפשר למצוא את הסיבה,” “יש עודף CPU אבל האפליקציה איטית,” ו-“רק סביבה מסוימת אחת איטית מאוד ב-boot.” אנחנו מטפלים בהכול כמעורבות אחת רציפה, מתכנון צילום עם WPR/WPA (איזו סביבה, איזה profile, וכמה לצלם) דרך ניתוח trace עד תיקון הסיבה בצד האפליקציה או בצד ההגדרות.

• Windows Custom Software Development
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

קישורים

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

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

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

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

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

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

מאיפה משיגים WPR ו-WPA? אפשר להשתמש בהם בסביבת לקוח שאי אפשר להתקין בה תוכנה?

כלי הצילום wpr.exe (גרסת command-line) מגיע עם Windows 8.1 ואילך, כך שאפשר להשתמש בו בלי התקנה נוספת. גרסת ה-GUI, WPRUI, וכלי הניתוח WPA (Windows Performance Analyzer) כלולים ב-Windows ADK (Windows Assessment and Deployment Kit) ודורשים התקנה נפרדת. בפועל, אם מפצלים את העבודה ל"בסביבת הלקוח מצלמים קובץ ETL רק עם wpr.exe הסטנדרטי של ה-OS, לוקחים הביתה, ומנתחים ב-WPA במחשב שלכם", אפשר לחקור ביצועים מערכתיים גם באתר שאי אפשר להוסיף בו תוכנה.

למה זה איטי כש-Task Manager מראה שיש עודף CPU? מה רואים ב-WPA?

כש-CPU usage נמוך ועדיין איטי, העבודה לא נכשלת בשימוש ב-CPU — היא עצורה כי היא מחכה למשהו. תחרות על locks, המתנה להשלמת I/O סינכרוני, והמתנה לתגובה מ-process אחר הם טיפוסיים. Task Manager מציג רק את התוצאה, ה-usage; CPU Usage (Precise) של WPA מציג, מרשומה לכל context switch, איפה ה-thread התחיל להמתין (NewThreadStack), כמה המתין (Waits), ומי העיר אותו (ReadyingProcess, ReadyThreadStack). בהליכה אחרי הצד שהמתין אותו אפשר לזהות את "האשם באיטיות" עד רמת הפונקציה.

כמה זמן לצלם trace? הקובץ לא יהיה ענק?

אם אפשר לשחזר את הבעיה, הבסיס הוא להתחיל ממש לפני השחזור, לעצור ממש אחרי, ולהשאיר את הצילום בתוך כמה דקות. ברירת המחדל של WPR היא Memory mode, שרושם למאגר מעגלי בזיכרון; events ישנים נדרסים, ולכן זה מתאים להמתנה לבעיה שתזמונה לא ידוע. File mode עם -filemode שומר הכול בקובץ רציף, אבל התקרה היחידה היא שטח דיסק פנוי, וקובץ גדול מדי עלול להפוך לבלתי-ניתן-לניתוח ב-WPA. משתמשים ב-Memory mode להמתנה ארוכה, וב-File mode לשחזור קצר ואמין.

איך בוחרים בין PerfView ל-WPA?

שני הכלים מטפלים ב-ETW traces, אבל החוזקות שונות. ל-PerfView יש הבנה עמוקה של ה-.NET runtime והוא חזק בחקירה ספציפית לאפליקציה מנוהלת כמו GC, allocation ו-JIT. WPA מתאים לקריאת CPU, דיסק, file I/O, צריכת חשמל וכדומה ברמת ה-OS על פני גרפים וטבלאות, והוא הבחירה הראשונה כש"זה לא אפליקציה מסוימת אלא כל ה-PC איטי", "כמה processes מעורבים", או "חשוד משהו מחוץ לאפליקציה (antivirus, driver, process אחר)". כלל אצבע: PerfView לאיטיות של אפליקציית ה-.NET שלכם לבדה, WPR/WPA לאיטיות של כל המערכת.

בסדר להריץ WPR בסביבת הייצור של הלקוח?

צילום קצר נפוץ בפועל, אבל הוא לא בטוח ללא תנאי. ETW קל, אבל רישום נפח גדול של events עם stacks צורך כמות מסוימת של CPU וזיכרון. מכניסים שיקולים כמו התחלה ממש לפני שלב השחזור ועצירה ממש אחרי, השארת הצילום בתוך כמה דקות, והרצה בזמן עם מעט השפעה עסקית, לאותו תהליך אישור כמו כל שינוי רגיל. גם, קובץ ETL מכיל מידע פנימי על המערכת כמו שמות processes, נתיבי קבצים ומידע על executables, ולכן צריך להחליט מראש איך יטופל אם הוא יוצא מהחברה (צמצום, תקופת שמירה, מחיקה).

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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