WPR/WPA בפועל — מבוא לחקירת ביצועים מערכתית כש"כל המחשב איטי"

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

כלים ברמת התהליך קיימים. גישה לקבצים ולרישום אפשר לראות עם Process Monitor, ומעבד ו-GC של יישום .NET אפשר לעקוב אחריהם עם PerfView. אבל סימפטום כמו “כל המחשב איטי” או “המעבד פנוי ועדיין איטי” מתחיל מזה שאפילו לא יודעים איזה תהליך הוא האשם. יישום A יכול להיות איטי בגלל סריקת אנטי-וירוס, או כי שירות אחר כותב בכבדות לדיסק, או בגלל שרשרת מנעולים שחוצה כמה תהליכים. מה שצריך הוא נתונים שרשמו לא את פנים התהליך אלא את מערכת ההפעלה כולה על ציר זמן אחד.

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

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

1. השורה התחתונה קודם

• הבחירה הראשונה לחקירת “כל המחשב איטי” היא WPR/WPA, שמצלם וקורא עקבת ETW ברמת מערכת ההפעלה. בעיות שכלים ברמת התהליך (מנהל המשימות, Procmon, PerfView) לא מצליחים לנעוץ אפשר לעקוב אחריהן אם מסתכלים על כל תהליך ועל הליבה על ציר זמן אחד.¹²
• כלי הצילום wpr.exe מגיע עם Windows 8.1 ואילך. אפשר להשתמש בו בלי התקנה נוספת. גרסת ה-GUI ‏(WPRUI) וכלי הניתוח WPA כלולים ב-Windows ADK.¹²
• ההליך הבסיסי הוא שלוש שורות. כמנהל, wpr -start GeneralProfile -filemode ← לשחזר את הבעיה ← wpr -stop C:\temp\trace.etl. זוכרים רק את זה ואפשר להתחיל לצלם.³
• הבסיס בשטח הוא פיצול “בסביבת הלקוח, רק לצלם עם wpr.exe; הקריאה היא WPA במחשב שלכם”. אפשר לצלם גם בשרת שאי אפשר להתקין בו תוכנה. זו אותה רעיון כמו בצילום מנות: “מצלמים בכלי סטנדרטי, קוראים ב-Wireshark”.¹
• קריאת WPA מתחילה בסיווג “מעבד, המתנה, או I/O”. אם המעבד בוער, CPU Usage (Sampled); אם המעבד פנוי ועדיין איטי, ניתוח המתנות ב-CPU Usage (Precise); אם הדיסק חשוד, Disk Usage — הנתיב מתפצל בהתחלה.⁴⁵
• CPU Usage (Sampled) מראה “איזו פונקציה השתמשה במעבד” מדגימה בערך כל 1 מילישנייה. אפשר ללכת אחרי הפירוק של ה-“50%” של מנהל המשימות מתהליך ← תהליכון ← מחסנית ← פונקציה.⁶
• CPU Usage (Precise) הוא רישום מלא של החלפות הקשר, ומספר “למי תהליכון חיכה”. הליכה אחרי Waits (זמן המתנה), ReadyingProcess (מי העיר אותו) ו-ReadyThreadStack (המחסנית של המעיר) היא הטכניקה שהמאמר הכי רוצה להעביר.⁴⁷
• קריאת מחסנית דורשת הגדרת סמלים. WPA מפנה כברירת מחדל לשרת הסמלים הציבורי של Microsoft. כדי לראות שמות פונקציות ביישום שלכם, מוסיפים את הנתיב ל-PDB שלכם.⁸
• קובץ ETL מכיל מידע פנימי על המערכת כמו שמות תהליכים ונתיבי קבצים. משאירים את הצילום במינימום הנדרש, ומחליטים איך יטופל אם הוא יוצא מהחברה לפני שמצלמים.

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

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

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

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

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

איור 1: בסביבת הלקוח רושמים עם wpr.exe הסטנדרטי של מערכת ההפעלה ומייצרים קובץ ETL; לוקחים הביתה ומנתחים ב-WPA שמותקן דרך ADK במחשב שלכם.

איך זה שונה מכלים דומים שווה לסדר קודם.

אם Procmon הוא יומן פעולות של “מה הוא עשה” ו-PerfView הוא “מה קרה בתוך .NET”, WPA הוא כלי שבודק “איפה נעלם הזמן” בכל תהליך. המכניקה של ETW עצמה, ואיך לכליל את היישום שלכם ב-ETW, מכוסות ב”מבוא ליומן האירועים של Windows ול-ETW”. אם היישום שלכם פולט אירועי ETW, נקודות הביקורת של היישום נרשמות באותה עקבה וקל הרבה יותר ליישר אותן. WPR, עם זאת, רושם רק אירועים מספקים שהפרופיל שבחרתם מפעיל. GeneralProfile לא כולל את הספקים שלכם, ולכן אם רוצים אותם מעורבבים, מכינים פרופיל רישום מותאם (.wprp) שמפעיל את הספקים שלכם ומשלבים אותו כ-wpr -start GeneralProfile -start MyApp.wprp!MyAppProfile, עם שם הפרופיל בתוך קובץ ה-.wprp ב-!³.

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

ההליך הבסיסי במסוף מנהל.

:: List of built-in profiles you can use
wpr -profiles

:: 1. Start capture (general-purpose profile, file mode)
wpr -start GeneralProfile -filemode

:: 2. Reproduce the issue (check capture status with wpr -status)

:: 3. Stop and save (you can attach a description of the problem).
::    Create the destination folder in advance (without it, -stop fails to save)
mkdir C:\temp 2>nul
wpr -stop C:\temp\slow-pc.etl "Reproduced the issue where the whole PC becomes slow while starting App X"

:: To abandon without saving
wpr -cancel

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

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

flowchart TB
    accTitle: זרימת הצילום של WPR ואיך בוחרים מצב
    accDescr: בעיה שאפשר לשחזר במקום מצולמת קצר ואמין במצב קובץ; בעיה שתזמונה לא ידוע ממתינים במאגר הטבעת של מצב הזיכרון כברירת מחדל. בעיה באתחול או בהתחברות משתמשת בעקבת אתחול. בכל מקרה הליך start / שחזור / stop זהה
    q{"מתי זה קורה?"}
    q -->|"במקום"| file["מצב קובץ: צילום קצר"]
    q -->|"תזמון לא ידוע"| mem["מצב זיכרון: המתנה（3.1）"]
    q -->|"אתחול או התחברות"| boot["עקבת אתחול（פרק 8）"]
    file --> s1["start ← שחזור ← stop"]
    mem --> s1

איור 2: בעיה שאפשר לשחזר במקום מצולמת קצר ואמין במצב קובץ; בעיה שתזמונה לא ידוע ממתינים במאגר הטבעת של מצב הזיכרון כברירת מחדל. בעיה באתחול או בהתחברות משתמשת בעקבת אתחול. בכל מקרה הליך start / שחזור / stop זהה.

3.1. מצב זיכרון ומצב קובץ — אפשר לשחזר, או ממתינים

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

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

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

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

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

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

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

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

1. כלל הזהב של טבלאות — סדר העמודות מחליט על הקיבוץ. לטבלת WPA יש שני פסים אנכיים, זהב וכחול, ועמודות משמאל לפס הזהב מדרגות (מקבצות) את הנתונים בסדר הזה, ועמודות מימין לפס הכחול הן צבירים.¹³ מסדרים אותן Process ← Stack ומקבלים צביר מחסנית לפי תהליך; Stack ← Process ומקבלים צביר של כל תהליך שמשתמש באותה מחסנית — גרירת עמודות לשינוי הסדר היא עצמה פעולת ניתוח. מבינים את הנקודה הזאת וכל טבלת WPA נקראת באותו אופן.

flowchart TB
    accTitle: כלל הזהב של טבלאות — שני הפסים ותפקיד העמודות
    accDescr: עמודות משמאל לפס הזהב מדרגות את הנתונים בסדר הזה; עמודות בין הפס הזהב לכחול הן עמודות תצוגה; עמודות מימין לפס הכחול הן צבירים. גרירת עמודות לשינוי הסדר היא עצמה פעולת ניתוח
    left["משמאל לזהב: קיבוץ"] --> gold["פס זהב"]
    gold --> mid["בין הפסים: תצוגה"]
    mid --> blue["פס כחול"]
    blue --> right["מימין לכחול: צבירים"]
    left -.-> op["גוררים עמודות לניתוח"]

איור 4: עמודות משמאל לפס הזהב מדרגות את הנתונים בסדר הזה; עמודות בין הפס הזהב לכחול הן עמודות תצוגה; עמודות מימין לפס הכחול הן צבירים. גרירת עמודות לשינוי הסדר היא עצמה פעולת ניתוח.

1. מצמצמים את טווח הזמן. גוררים על הגרף לבחירת טווח, ואז לחיצה ימנית ו-“Zoom”, והצביר מתחלף רק למרווח הזה. חקירת ביצועים תמיד, כעיקרון, מסתכלת רק על “המרווח שבו הבעיה קרתה” (פרק 9).
2. מגדירים סמלים. כדי לקרוא מחסנית לפי שם פונקציה, מריצים Trace > Load Symbols מהתפריט.¹⁴ כברירת מחדל הוא מפנה לשרת הסמלים הציבורי של Microsoft ‏(msdl.microsoft.com), כך שמחסניות של Windows עצמו ניתנות לפתרון אם יש חיבור לאינטרנט. כדי לראות שמות פונקציות ביישום שלכם, מוסיפים את תיקיית ה-PDB של היישום ב-Trace > Configure Symbol Paths.⁸ מהו PDB, ולמה תמיד כדאי לשמור אותו גם לבניית Release, מסוכם ב”מהו PDB ‏(Program Database)?”. לתמונות native של .NET Framework NGen, WPR מייצר NGen PDB ‏(.ngenpdb) בזמן הצילום ומניח אותם בתיקייה ליד העקבה, ו-WPA מפנה אליהם אוטומטית.⁸ זה מנגנון לתמונות NGen בלבד, וקוד יישום .NET רגיל ב-JIT שלכם מחוץ להיקף. המיפוי מכתובת קוד JIT לשם פונקציה נפתר מאירועי JIT שה-CLR פולט, ולכן כשחוקרים יישום .NET, מכינים פרופיל רישום (.wprp) שמפעיל את ספקי ה-CLR ‏(Microsoft-Windows-DotNETRuntime ו-Rundown התואם) ומשלבים אותו באותו אופן כמו הספקים שלכם בפרק 3, wpr -start GeneralProfile -start MyDotNet.wprp!profile-name, כדי שאירועי CLR ייכללו בעקבה (אפשר לבדוק אילו פרופילים מובנים ה-WPR המקומי מציע עם wpr -profiles). מעל זה, שומרים את ה-PDB שנוצרו בבנייה למיפוי לשורות מקור, ומוסיפים אותם לנתיב הסמלים למעלה.

flowchart TB
    accTitle: פתרון סמלים לקריאת מחסנית לפי שם פונקציה
    accDescr: הרצת Trace Load Symbols פותרת את Windows עצמו משרת הסמלים הציבורי של Microsoft, ואת היישום שלכם מ-PDB בנייה שנוספו לנתיב הסמלים. תמונות NGen משתמשות ב-NGen PDB ש-WPR מייצר; קוד .NET ב-JIT נפתר מאירועי CLR JIT בעקבה פלוס PDB בנייה
    load["Trace > Load Symbols"] --> ms["Windows: סמלים ציבוריים"]
    load --> own["היישום שלכם: PDB בנייה"]
    ms -.-> ngen["NGen: WPR .ngenpdb"]
    own -.-> jit["JIT: אירועי CLR + PDB"]

איור 5: הרצת Trace Load Symbols פותרת את Windows עצמו משרת הסמלים הציבורי של Microsoft, ואת היישום שלכם מ-PDB בנייה שנוספו לנתיב הסמלים. תמונות NGen משתמשות ב-NGen PDB ש-WPR מייצר; קוד .NET ב-JIT נפתר מאירועי CLR JIT בעקבה פלוס PDB בנייה.

ברגע שמוכנים, נכנסים מהפיצול הבא. במרווח הזה, האם המעבד היה גבוה, או נמוך? אם גבוה, פרק 5 (Sampled); אם נמוך ועדיין איטי, פרק 6 (Precise).

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

איור 6: מתקרבים למרווח הבעיה; אם המעבד גבוה הולכים ל-CPU Usage Sampled; אם נמוך ועדיין איטי, בודקים נעיצת ליבה אחת / תהליכון אחד ואז ניתוח המתנות ב-CPU Usage Precise; אם הדיסק חשוד, Disk Usage ו-File IO.

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

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

flowchart TB
    accTitle: איך CPU Usage Sampled עובד
    accDescr: בערך כל 1 מילישנייה נרשמת המחסנית שרצה על כל מעבד, ויחס הדגימות המצטבר הוא פירוק זמן המעבד. קוראים מתהליך לתהליכון, מחסנית ופונקציה. פעילות קצרה שמסתיימת בין דגימות לא מופיעה
    tick["הפרעה בערך כל 1 מילישנייה"] --> snap["רישום המחסנית הרצה"]
    snap --> agg["יחס דגימות = פירוק מעבד"]
    agg --> drill["תהליך ← תהליכון ← מחסנית"]
    snap -.-> miss["פעילות בין דגימות מוחמצת"]

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

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

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

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

זה הליבה של המאמר. לפני שממשיכים לניתוח המתנות, יש דבר אחד לאשר. “שימוש המעבד הכולל נמוך” לא אומר “המעבד אינו צוואר הבקבוק”. במחשב עם 16 ליבות, עבודה טורית שנעוצה לליבה אחת (תהליכון UI שרץ במלוא הקיטור) נראית רק כ-6% כולל. קודם בודקים ב-Sampled של פרק 5 (או Utilization by CPU של CPU Usage (Precise)) שאין נעיצה לליבה או תהליכון מסוימים, ואם אין, מגיעים לפרק הזה — העבודה לא לא מצליחה לרוץ, היא מחכה. מה שמספר למה היא מחכה הוא CPU Usage (Precise).

איפה Sampled הוא דגימה, Precise הוא רישום מלא של החלפות הקשר (החלפות תהליכונים). תהליכון נכנס להמתנה, מישהו מעיר אותו (Ready), והוא נוחת על מעבד — הלוך ושוב הזה נשאר שורה אחת בכל פעם, ואפשר לקרוא את העמודות הבאות.⁷⁴

flowchart TB
    accTitle: הלוך ושוב אחד של המתנה ואיך העמודות מתאימות
    accDescr: תהליכון נכנס להמתנה על המחסנית שנשארת ב-NewThreadStack, וממתין את זמן Waits. כשמישהו מעיר אותו, הצד הזה נשאר ב-ReadyingProcess וב-ReadyThreadStack; הוא ממתין את זמן Ready לתחרות על מעבד ואז רץ שוב
    run1["רץ"] -->|"כניסה להמתנה"| waitst["המתנה（Waits us）"]
    waitst -->|"מישהו מעיר אותו"| ready["Ready（תחרות על מעבד）"]
    ready -->|"נוחת על מעבד"| run2["רץ שוב"]
    waitst -.-> col["NewThreadStack / ReadyingProcess"]

איור 8: תהליכון נכנס להמתנה על המחסנית שנשארת ב-NewThreadStack, וממתין את זמן Waits. כשמישהו מעיר אותו, הצד הזה נשאר ב-ReadyingProcess וב-ReadyThreadStack; הוא ממתין את זמן Ready לתחרות על מעבד ואז רץ שוב.

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

1. מחילים את ה-preset Utilization by Process, Thread ומוסיפים NewThreadStack ו-ReadyThreadStack לעמודות.
2. קודם מזהים את התהליכון שביצע את הפעולה המאוחרת (תהליכון ה-UI, התהליכון שמטפל בבקשה הנוגעת בדבר). הסתכלות רק בסדר יורד של סך Waits מבלבלת, כי תהליכונים ש”מחכים בכוונה כל הזמן”, כמו משאבת הודעות או טיימר, תופסים את הראש. אחרי שמצאתם את תהליכון היעד, אם CPU Usage (ms) שלו גדול זו בעיית מעבד של פרק 5; אם Waits שולטים זו בעיית המתנה.
3. מרחיבים NewThreadStack ורואים מה הוא עשה כשעצר. WaitForSingleObject או EnterCriticalSection היא המתנת מנעול; בתוך I/O סינכרוני כמו ReadFile זו המתנת I/O; בתוך קבלת socket זו המתנה לתגובת העמית.
4. אחר כך רואים מי שחרר את ההמתנה. מרחיבים ReadyThreadStack ובודקים ReadyingProcess / ReadyingThreadId. אם הוא הוער מ-KiTimerExpiration של הליבה זה היה טיימר (= הוא ישן עד פקיעת זמן); אם הוא הוער מטיפול השלמת I/O, זה מאשר שהייתה המתנת I/O.⁴
5. אם הצד שהעיר אותו הוא תהליכון אחר או תהליך אחר, חוקרים את התהליכון הזה באותו הליך. “A חיכה ש-B ישחרר מנעול, B חיכה לתגובת RPC של C, C חיכה ל-I/O דיסק” — מה שיש כשהלכתם בשרשרת הזאת עד השורש הוא הנתיב הקריטי של העיכוב.⁷

flowchart TB
    accTitle: שרשרת הנתיב הקריטי שהולכים בה בניתוח המתנות
    accDescr: רואים ב-NewThreadStack של תהליכון A המאוחר מה הוא עשה כשעצר, מזהים את המעיר B מ-ReadyThreadStack ומ-ReadyingProcess, וחוקרים את B באותו הליך עד I/O הדיסק בשורש
    a["תהליכון A（עבודה מאוחרת）"] -->|"המתנת מנעול"| b["תהליכון B（מחזיק מנעול）"]
    b -->|"המתנת RPC"| c["תהליך C"]
    c -->|"המתנת I/O סינכרוני"| d["I/O דיסק（שורש）"]
    d -.->|"השלמה מעירה את C"| c
    c -.->|"תגובה מעירה את B"| b
    b -.->|"שחרור מנעול מעיר את A"| a

איור 9: רואים ב-NewThreadStack של תהליכון A המאוחר מה הוא עשה כשעצר, מזהים את המעיר B מ-ReadyThreadStack ומ-ReadyingProcess, וחוקרים את B באותו הליך עד I/O הדיסק בשורש.

במקרה כמו “הפכנו לרב-תהליכוני ולא נהיה מהיר יותר”, ההליך הזה מראה כל עובד מיושר על מנעול אחד כמו שהוא. הימנעות מתחרות על מנעולים בתכנון מכוסה ב”שיטות עבודה מומלצות לרב-תהליכוניות בפועל: מהדורת .NET”, ומנגנון Windows שרץ על הודעת השלמה במקום להמתין ב-I/O סינכרוני מכוסה ב”יציאות השלמת I/O ‏(IOCP) ומאגר התהליכונים של .NET”. נעיצת “למי הוא חיכה” ב-WPA ותיקון עם אותם טיעוני תכנון הם זרימה אחת רציפה.

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

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

Disk Usage הוא רישום של I/O דיסק, ושתי עמודות חשובות. Disk Service Time הוא הזמן שמכשיר הדיסק באמת בילה בעיבוד ה-I/O הזה; IO Time הוא הזמן מכניסת ה-I/O לתור של מערכת ההפעלה עד שהושלם. IO Time תמיד לפחות Service Time בכמות התור, ולכן אם IO Time ארוך בהרבה מ-Service Time, ה-I/O הזה “חיכה בתור”.⁶ זה לבדו, עם זאת, לא מחליט אם האשם שיצר את התור הוא תהליך אחר, או רק I/O כבד של אותו תהליך עצמו שיושר על מכשיר איטי. לא מסיקים כאן; מכריעים עם Service Time (תגובת המכשיר עצמו) והפירוק הבא לפי תהליך, נתיב ומחסנית.

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

• אנטי-וירוס סרק כל קובץ. בחלון שבו היישום היה איטי להתחיל, תהליך האנטי-וירוס נראה מנפיק נפח גדול של קריאות. שם תהליך, נתיב ונפח הם ראיה כמו שהם לדיון בהחרגות.
• תהליך אחר כתב בכבדות. גיבוי, המפענח, יומנים שנכתבו יותר מדי וכדומה. מתי כתיבה מגיעה לדיסק מעורב בו מנהל המטמון, ולכן העובדה ש”הרגע שכתבתם” ו”הרגע שהדיסק עסוק” יכולים להתרחק מכוסה גם ב”מנהל המטמון — מתי WriteFile שלכם באמת מגיע לדיסק?”.

File I/O הוא שכבה אחת למעלה, רישום של פעולות קבצים שהיישום הנפיק (Create/Read/Write וכדומה), ו-presets כמו Duration by Process, Thread, Type יכולים לצבור זמן לפי שם קובץ ולפי פעולה.¹⁵ מקרה שמבלה זמן במערכת הקבצים או במנהל סינון לפני שהוא מגיע לדיסק לא מופיע ב-Disk Usage, ולכן אי-ההתאמה עצמה — “Disk Usage שקט אבל File I/O איטי” — היא רמז. אם רוצים להתחיל ממכניקת I/O סינכרוני ואסינכרוני, ראו “I/O סינכרוני ואסינכרוני — מה OVERLAPPED באמת אומר”.

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

איור 10: פעולת קובץ של היישום עוברת דרך מערכת הקבצים ומנהלי סינון מתור ה-I/O של מערכת ההפעלה למכשיר הדיסק. File IO רושם פעולות בשכבה העליונה; Disk Usage רושם I/O שהגיע לדיסק; ההפרש בין IO Time ל-Disk Service Time הוא זמן תור.

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

8. אתחול והתחברות איטיים — הכניסה לעקבת אתחול

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

:: 1. Arrange automatic recording on the next boot
wpr -boottrace -addboot GeneralProfile -filemode

:: 2. Restart (reproduce the slow boot)

:: 3. After boot, stop recording and save (the arrangement is also cleared)
mkdir C:\temp 2>nul
wpr -boottrace -stopboot C:\temp\boot.etl "Issue where boot takes 3 minutes"

flowchart TB
    accTitle: זרימת עקבת אתחול
    accDescr: אחרי שמסדרים רישום אוטומטי באתחול הבא עם addboot ומאתחלים, מערכת ההפעלה מתחילה לרשום אוטומטית באתחול. שמירה עם stopboot אחרי התחברות גם מנקה את הסידור. כדי לוותר, מנקים עם cancelboot
    add["wpr -boottrace -addboot"] --> rebootpc["אתחול（אתחול איטי）"]
    rebootpc --> auto["מערכת ההפעלה רושמת באתחול"]
    auto --> stop2["אחרי התחברות: -stopboot"]
    add -.-> cancel["ויתור: -cancelboot"]

איור 11: אחרי שמסדרים רישום אוטומטי באתחול הבא עם addboot ומאתחלים, מערכת ההפעלה מתחילה לרשום אוטומטית באתחול. שמירה עם stopboot אחרי התחברות גם מנקה את הסידור. כדי לוותר, מנקים עם cancelboot.

מדידת האתחול והכיבוי ש-xbootmgr נהג להחזיק אפשר גם להריץ ב-WPR הנוכחי עם אפשרויות כמו -onoffscenario Boot.³ עקבה שצולמה נקראת באותה ערכת כלים כמו הפרקים הקודמים. מסתכלים איזה תהליך נולד מתי על ציר זמן בגרף Processes, מתקרבים לחלון שבו האתחול תקוע, ומסווגים מעבד, המתנה או דיסק — יישום הפעלה שמחכה למשהו בטור, התחלת שירות תקועה על I/O מסוים וכדומה הופכים לנראים. ניתוח אתחול הוא התמחות עמוקה בפני עצמה, ולכן המאמר הזה מגיע רק עד הכניסה: “בעיה שאי אפשר לתפוס ביד עדיין אפשר לצלם עם WPR”. מתחילים בהבנת התמונה הכוללת עם עקבת אתחול GeneralProfile.

9. דפוס עבודה — סיווג ← התקרבות ← מחסנית, חוזר

עכשיו שהכלים ברורים, הנה הדפוס לחקירה כולה.

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

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

איור 12: נועצים את זמן התופעה, מתקרבים למרווח, מסווגים מעבד / המתנה / I/O, מגבשים השערה ומצמצמים, וגיבים במחסנית. אם זה מחזיק, הסיבה מאושרת; אם לא, חוזרים עם ההשערה הבאה.

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

flowchart TB
    accTitle: מה קובץ ETL משקף, ואיך מטפלים בו
    accDescr: ETL משקף כל שם תהליך, נתיבים של קבצים שנפתחו, מודולים, ובהתאם לפרופיל שמות מפתחות רישום; הפעלת ספק מותאם כוללת גם את המטען שלו. מתייחסים כסודי: המינימום הנדרש של צילום, הסכמה עם הצד השני, ותקופת שמירה ומחיקה
    etl["קובץ ETL"] --> a1["שמות, נתיבים, מודולים"]
    a1 --> a2["מפתחות רישום（חלק）"]
    a2 --> a3["מטען מותאם"]
    a3 -.-> rule["מתייחסים כסודי"]

איור 13: ETL משקף כל שם תהליך, נתיבים של קבצים שנפתחו, מודולים, ובהתאם לפרופיל שמות מפתחות רישום; הפעלת ספק מותאם כוללת גם את המטען שלו. מתייחסים כסודי: המינימום הנדרש של צילום, הסכמה עם הצד השני, ותקופת שמירה ומחיקה.

10. סיכום

• “כל המחשב איטי” שמנהל המשימות לא מצליח להסביר חוקרים עם עקבת ETW ברמת מערכת ההפעלה — צילום ב-WPR, קריאה ב-WPA. wpr.exe מגיע עם Windows 8.1 ואילך, כך שפיצול של צילום בסביבת הלקוח, לקיחת ה-ETL הביתה, וקריאה ב-WPA במחשב שלכם מחזיק.
• הצילום הוא שלושת הצעדים wpr -start GeneralProfile -filemode ← שחזור ← wpr -stop trace.etl. אם אפשר לשחזר, מצב קובץ בתוך כמה דקות; אם ממתינים, מצב זיכרון (מאגר טבעת). ארוך יותר אינו טוב יותר.
• אפשר להתחיל WPA אחרי שקלטו שלוש נקודות: כלל הזהב של טבלאות (משמאל לפס הזהב = קיבוץ), התקרבות לטווח הזמן, והגדרת סמלים (היישום שלכם צריך PDB).
• אם המעבד גבוה, הולכים תהליך ← מחסנית ← פונקציה ב-CPU Usage (Sampled). אם המעבד נמוך ועדיין איטי, הולכים בשרשרת NewThreadStack (מה הוא עשה כשעצר) ← Waits (כמה המתין) ← ReadyingProcess ו-ReadyThreadStack (מי העיר אותו) עד השורש ב-CPU Usage (Precise).
• לדיסק, רואים “זמן שביליתם בתור” מההפרש בין Disk Usage IO Time ל-Service Time, ומזהים את הסיבה (האם המכשיר עצמו איטי, או מי יצר את התור) מ-Service Time ומהפירוק לפי תהליך, נתיב ומחסנית. אתחול איטי אפשר לצלם עם wpr -boottrace.
• דפוס העבודה הוא (1) נעיצת הזמן (2) התקרבות למרווח (3) סיווג מעבד, המתנה או I/O (4) חזרה על השערה ← התקרבות ← מחסנית. מתייחסים ל-ETL כסודי כי הוא מכיל מידע פנימי.

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

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

• איתור “איטי” עם PerfView ו-dotnet-trace — מבוא מעשי לחקירת ביצועי .NET
• מדריך מעשי ל-Process Monitor ‏(ProcMon) — איתור “הגדרות לא הוחלו” ו-“ACCESS DENIED” ב-10 דקות
• מבוא ליומן האירועים של Windows ול-ETW — הנחת יומני היישום העסקי על מנגנוני הסטנדרט של מערכת ההפעלה
• מה “שימוש בזיכרון” של Windows באמת אומר? — קריאה נכונה של Working Set, Private Bytes, Commit וקובץ העמוד
• תזמון המעבד ב-Windows - שירותי רקע וליבות P/E
• מהו PDB ‏(Program Database)? — הבנת מידע ניפוי באגים, סמלים ו-Source Link

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

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

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

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

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

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

למה זה איטי כשמנהל המשימות מראה שיש עודף מעבד? מה רואים ב-WPA?

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

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

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

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

שני הכלים מטפלים בעקבות ETW, אבל החוזקות שונות. ל-PerfView יש הבנה עמוקה של זמן הריצה של .NET והוא חזק בחקירה ספציפית ליישום מנוהל כמו GC, הקצאה ו-JIT. WPA מתאים לקריאת מעבד, דיסק, I/O קבצים, צריכת חשמל וכדומה ברמת מערכת ההפעלה על פני גרפים וטבלאות, והוא הבחירה הראשונה כש"זה לא יישום מסוים אלא כל המחשב איטי", "כמה תהליכים מעורבים", או "חשוד משהו מחוץ ליישום (אנטי-וירוס, מנהל, תהליך אחר)". כלל אצבע: PerfView לאיטיות של יישום ה-.NET שלכם לבדו, WPR/WPA לאיטיות של כל המערכת.

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

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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