מעמקי זיכרון Windows (חלק 2) — חיי דף פיזי: חמש רשימות והאמת על קובץ ההחלפה

במאמר הקודם, «מעמקי זיכרון Windows (חלק 1) — הרגע שבו כתובת וירטואלית הופכת ל-RAM פיזית», עקבנו עד הרגע שבו מטפל שגיאת הדף מקצה דף פיזי במגע הראשון בדף שכבר ב-Commit. לאן הולך הדף הפיזי הזה אחרי שהוא מוסר מ-Working Set?

לעיתים קרובות מצמצמים את ההסבר ל«הוא מגורש לקובץ ההחלפה», אבל במציאות יש כמה מצבים לפני ואחרי. דף שלא שונה יכול לעבור ל-Standby ולהשאיר את התוכן במקום. דף ששונה מחכה קודם לכתיבה חוזרת ב-Modified. בשימוש חוזר הוא עשוי לעבור ב-Free או Zeroed, ואם צריך שוב את אותו תוכן הוא יכול לחזור מ-Standby בשגיאה רכה (soft fault).

המאמר הזה לוקח את מסד PFN כציר ועוקב איך דף פיזי אחד נע דרך Active, Modified, Standby, Free ו-Zeroed. קריאת המספרים עצמם מניחה את מאמר המבוא «What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File».

«מעמקי זיכרון Windows» — כל 3 החלקים

1. חלק 1: כתובות וירטואליות ושגיאות דף
   אנחנו עוקבים מתי דף וירטואלי ב-Commit מקבל RAM פיזית.
2. חלק 2 (המאמר הזה): חיי דף פיזי
   אנחנו עוקבים אחרי מעברי מצב של דף שיוצא מ-Working Set, ואחרי תפקיד קובץ ההחלפה.
3. חלק 3: אובייקטי מקטע והעתקה בכתיבה
   אנחנו עוקבים אחרי המנגנון שבו DLL, מיפויי קבצים וזיכרון משותף חולקים דפים פיזיים.

השאלה שחלק 2 עונה עליה היא אחת בלבד.

האם דף פיזי שיוצא מ-Working Set נעלם, הולך לדיסק, או נשאר ב-RAM?

הקוראים המיועדים הם מפתחים ומפעילים שרוצים להבין מהמנגנון למה Available גבוה וגם Standby גבוה, התנהגות אחרי גיזום Working Set, הגדרת קובץ ההחלפה ודחיסת זיכרון. הדרישות הן Windows 10/11 או Windows Server עדכני, והרקע הנדרש הוא יסודות Working Set, Commit ושגיאות רכות/קשות. רמת הקושי בינונית; אנחנו משתמשים במונחים פנימיים כמו PFN ורשימות דפים, אבל מתמקדים במה שאפשר לצפות ב-RAMMap וב-PerfMon בלי מנפה באגים של ליבה.

1. קודם המסקנה

להתחלה, הנקודות שקל לקרוא לא נכון.

• דף שיוצא מ-Working Set לא בהכרח נעלם מיד.
  דף נקי נשאר ב-Standby ויכול לחזור בלי לקרוא דיסק אם צריך את אותו תוכן.
• דף ששונה אי אפשר לעשות בו שימוש חוזר מיד.
  תוכן פרטי נהיה לשימוש חוזר אחרי שאפשר לכתוב אותו לקובץ ההחלפה; קובץ ממופה, אחרי שאפשר לכתוב אותו לקובץ המתאים; וכן הלאה.
• Available כולל Standby.
  Standby הוא מטמון שעדיין מחזיק תוכן, ובאותו זמן מועמד לשימוש חוזר שאפשר לקחת מיד אם צריך.¹
• הכתיבה לקובץ ההחלפה אינה משימה באצווה שמתחילה רק אחרי ש-RAM נגמר לגמרי.
  היא מתקדמת ברקע לפי רשימת Modified ולחץ הזיכרון.²³
• קובץ ההחלפה אינו רק «RAM איטית».
  הוא מרחיב את Commit Limit, נהיה מאגר גיבוי לדפים פרטיים ששונו, ותומך ב-dump של קריסה.⁴
• כיבוי קובץ ההחלפה לא מתקן דליפת זיכרון.
  Commit Limit יורד, ואפשר לאבד אפשרויות לשימוש יעיל ב-RAM ואת היכולת ללכוד dump.

במשפט אחד: לפני ש-Windows זורק דף, הוא בודק את האפשרות שיידרש שוב והאם יש מקום שממנו אפשר לשחזר את התוכן המקורי.

2. מסד PFN — ספר החשבונות בצד ה-RAM הפיזית

ה-PTE שראינו בחלק 1 ייצגה את התרגום מדף וירטואלי לדף פיזי. ספר החשבונות שמסתכל על זה מצד הדף הפיזי ועוקב «למה משמש דף ה-RAM הזה עכשיו» הוא מסד PFN. PFN הוא Page Frame Number: RAM פיזית ממוספרת ביחידות דף.

רשומת PFN עוקבת מושגית אחרי המידע הבא.

• המצב הנוכחי של הדף הפיזי
• מונה הפניות ומונה השיתוף
• ה-PTE המתאים
• האם הוא שונה
• לאיזו רשימת דפים הוא שייך
• מידע שקשור לצומת NUMA ולעדיפות

ב-WinDbg, !pfn מציג מידע על PFN מסוים, ו-!memusage מציג שימוש בזיכרון פיזי וסיכומים לכל רשימת דפים.⁵⁶ כדי לצפות באותו עולם בלי מנפה באגים של ליבה זמין Sysinternals RAMMap. Use Counts מציג ייעוד ורשימת דפים, Priority Summary מציג Standby לפי עדיפות, ו-Physical Pages מציג שימוש לפי דף.⁷

3. לחבר את חמשת המצבים בתרשים אחד

המאמר מטפל בזרימת דף פיזי כחמשת המצבים הבאים, מפושטים. בקפדנות, ל-Windows הנוכחי יש מצבים ורשימות שלא מצוירים כאן — Standby לפי עדיפות, Transition, Bad ואחרים — ו-Active מתייחס פחות ל«רשימת Active» אחת מאשר למצב של הפניה מ-Working Set או דומה דרך PTE תקף. גם כך התרשים הזה יותר משימושי לקריאת התנהגות הזיכרון של אפליקציה.

איור 1: דף שמופנה אליו ב-Working Set עובר ל-Standby אם הוא נקי ול-Modified אם הוא מלוכלך. אותו תוכן יכול לחזור; שימוש אחר עושה שימוש חוזר בדף ישירות או עובר ב-Free/Zeroed לקראת הקצאה שדורשת אפסים.

הנקודה החשובה ביותר בתרשים היא שיציאה מ-Working Set ואובדן התוכן אינם אותו דבר. גם כשלוקחים דף Standby למטרה אחרת, הוא לא בהכרח עובר ב-Free/Zeroed לפי הסדר. אם יימסר למצב משתמש כדף פרטי demand-zero חדש, צריך למחוק את התוכן הישן; אם כל הדף יידרס, כמו יעד של קריאת קובץ, אפשר להסיר את זהות Standby ולעשות שימוש חוזר בדף ישירות.

4. Active / Valid — דף פיזי שאפשר להפנות אליו עכשיו

דף Active/Valid מופנה אליו מ-Working Set של תהליך או ממרחב המערכת דרך PTE תקף. המעבד מגיע אליו בתרגום כתובות רגיל, ולכן הגישה עצמה לא צריכה שגיאת דף.

אין עם זאת ערובה שהדף יישאר Active. כדי לשמור זיכרון זמין, מנהל הזיכרון מסתכל על גודל Working Set, כמה לאחרונה השתמשו בדף וגורמים דומים, וגוזם דפים מועמדים. תיעוד Working Set של Microsoft מסביר גם שמנהל הזיכרון מסיר דפים מ-Working Set כדי ליצור זיכרון זמין.⁸

4.1. גיזום אינו שחרור

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

• הסרה מ-Working Set
• שחרור Commit
• שחרור טווח כתובות וירטואלי
• אובדן הנתונים המקוריים

הפעלת EmptyWorkingSet או «Trim Working Set» של כלי אינה תחליף ל-VirtualFree או שחרור ערימה. אם נוגעים שוב באותו דף, הוא חוזר בשגיאה רכה מ-Standby או בשגיאה קשה ממאגר גיבוי. לכן «הקטנתי את Working Set» לא אומר «תיקנתי את הדליפה».

5. דף נקי הולך ל-Standby

גם אחרי שהדף הוסר מ-Working Set, אם התוכן עדיין תואם לקובץ המקורי או שיש לו כבר מאגר גיבוי בטוח, אפשר לשים אותו ב-Standby. דוגמאות מייצגות:

• קוד EXE/DLL שלא שונה
• קובץ ממופה בזיכרון שלא שונה
• דף פרטי שכבר נכתב בחזרה
• נתונים שנשארו במטמון הקבצים

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

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

הדו-צדדיות הזו היא בדיוק הסיבה ש-Standby הוא גם מטמון וגם Available.

5.1. למה Available כולל Standby

MEMORYSTATUSEX.ullAvailPhys מייצג זיכרון פיזי שאפשר לעשות בו שימוש חוזר מיד בלי כתיבה לדיסק, והוא סכום Standby, Free ו-Zeroed.¹

flowchart LR
    accTitle: שלוש רשימות הדפים שמרכיבות את Available
    accDescr: הזיכרון הפיזי הזמין הוא סכום Standby, Free ו-Zeroed; דפי Active שמופנים אליהם ב-Working Set אינם כלולים
    standby["Standby（מועמד לשימוש חוזר ששומר את התוכן）"] --> avail["Available（זיכרון פיזי זמין）"]
    free["Free（לא בשימוש, לא מאופס）"] --> avail
    zeroed["Zeroed（לא בשימוש ומאופס）"] --> avail
    active["Active（מופנה אליו ב-Working Set）"] -.->|לא כלול| avail

איור 2: Available הוא סכום Standby, Free ו-Zeroed. גם Standby, שעדיין מחזיק את התוכן, נספר כ«זמין».

לכן אין סתירה כשמנהל המשימות מציג «Free נמוך, אבל Cached/Standby גבוה ו-Available מספיק». Windows לא משאיר RAM פנוי בטל; הוא משאיר קבצים וקוד שנעשה בהם שימוש לאחרונה ב-Standby כדי לעשות בהם שימוש חוזר מהר כמטמון אם צריך, ולוקח אותם אם מטרה אחרת צריכה אותם.

אל תסיקו «Free נמוך, אז חסר לנו זיכרון מיד»; הסתכלו יחד על Available, Commit, שגיאות קשות ועיכוב עיבוד.

6. דף מלוכלך מחכה ב-Modified

כשאפליקציה כותבת לדף, התוכן כבר לא תואם למאגר הגיבוי המקורי. דריסת הדף המלוכלך הזה למטרה אחרת תאבד את הנתונים. לכן דף ששונה והוסר מ-Working Set מחכה לכתיבה חוזרת ב-Modified.

יעד הכתיבה החוזרת תלוי בסוג הדף.

תיעוד קובץ ההחלפה של Microsoft מסביר גם שקבצי .dll, .exe וקבצים רגילים שכבר קיימים בדיסק לא צריכים להיכתב שוב לקובץ ההחלפה, ושנתונים ששונו בלי עותק דיסק מקורי הם שנהיים מועמדים לקובץ ההחלפה.²

6.1. Modified Page Writer

Modified Page Writer הוא עובד מערכת שסורק דפים מלוכלכים עם גיבוי בקובץ ההחלפה שמנהל הזיכרון עוקב אחריהם, וכותב אותם לקובץ ההחלפה.³ בצד הקובץ הממופה יש נתיבים כמו Mapped Page Writer שמשתפים פעולה עם מערכת הקבצים ומנהל המטמון כדי לכתוב בחזרה לקובץ המתאים.

הנקודה החשובה היא שהכתיבה אינה סכמה של «לא לעשות כלום עד ש-RAM הוא 0 בתים». Windows מכין ברקע דפים שאפשר יהיה לעשות בהם שימוש חוזר בעתיד, לפי רשימת Modified, Available, מצב קובץ ההחלפה וגורמים דומים. כשהכתיבה החוזרת מסתיימת ואין הפניות תקפות אחרות, הדף מתקדם ל-Standby עם התוכן שלו.

flowchart TB
    accTitle: נתיבי כתיבה חוזרת של דף ששונה
    accDescr: דף ששונה ויוצא מ-Working Set מחכה ברשימת Modified; לדף פרטי, אם מוגדר קובץ החלפה, Modified Page Writer כותב אותו לקובץ ההחלפה, ודף של קובץ ממופה נכתב בחזרה לקובץ הנתונים המתאים על ידי Mapped Page Writer או דומה, ואז מתקדם ל-Standby עם התוכן
    dirty["דף ששונה ויצא מ-Working Set"] --> modified["המתנה לכתיבה חוזרת ברשימת Modified"]
    modified -->|"דף פרטי（כשקובץ החלפה מוגדר）"| mpw["Modified Page Writer כותב לקובץ ההחלפה"]
    modified -->|דף של קובץ ממופה| mapped["Mapped Page Writer או דומה כותב לקובץ המתאים"]
    mpw --> standby["אחרי כתיבה חוזרת, ל-Standby עם התוכן"]
    mapped --> standby

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

6.2. להפריד פלט דפים מקלט/פלט ספציפי לקובץ ההחלפה

המונים הבאים קל לבלבל; ודאו מה הם אומרים.

• Memory\\Page Writes/sec: מספר פעולות קלט/פלט כתיבת עימוד שהונפקו כדי לפנות זיכרון פיזי
• Memory\\Pages Output/sec: מספר הדפים שנכתבו לדיסק בכתיבות האלה
• Memory\\Page Reads/sec: מספר פעולות קלט/פלט קריאה מדיסק שהונפקו כדי לפתור שגיאות קשות
• Memory\\Pages Input/sec: מספר הדפים שנכנסו ל-RAM מהקריאות האלה

שימו לב ש-Page Writes/sec ו-Pages Output/sec אינם מונים שמזהים רק את קובץ ההחלפה. הם יכולים לעלות גם בנתיב שכותב בחזרה דפים מלוכלכים עם גיבוי בקובץ, כמו קבצים ממופים. ולהפך, צד הקלט גם הוא לא מבדיל בין קובץ ההחלפה, DLL, EXE וקבצים ממופים בזיכרון.² אם רוצים לזהות קלט/פלט ספציפי ל-pagefile.sys, אל תעריכו רק מארבעת המונים האלה; רשמו File I/O ו-Disk I/O עם ETW/WPA ואשרו את קובץ היעד בהתאמת FileObject ו-FileName.⁹

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

7. ההבדל בין Standby, Free ו-Zeroed

7.1. Standby

מצב שעדיין מחזיק את ההתאמה לתוכן הקודם.

• אם צריך את אותו תוכן, הוא יכול לחזור בשגיאה רכה
• אם מטרה אחרת צריכה אותו, אפשר לזרוק את הזהות הישנה ולעשות שימוש חוזר
• יש רשימות Standby לפי עדיפות

7.2. Free

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

7.3. Zeroed

התוכן אפס, ואפשר למסור את הדף בבטחה כדף חדש במצב משתמש. שגיאת demand-zero בחלק 1 הייתה מקרה מייצג של קבלת דף Zeroed זמין וקישור ל-PTE. ההכנה מ-Free ל-Zeroed נעשית לפי ביקוש ומצב המערכת.

לכן אף ש«Free» ו«Zeroed» נראים שניהם לא בשימוש, הם נבדלים במוכנות הקשורה לאבטחה.

8. מאגר דחיסת הזיכרון — ליצור עוד יעד בתוך RAM

מ-Windows 10 ואילך, כשיש לחץ זיכרון מנהל הזיכרון יכול במקרים מסוימים לדחוס ב-RAM דפים שנעשה בהם שימוש לעיתים רחוקות במקום לכתוב אותם מיד לדיסק. אוסף הדפים הדחוסים הזה הוא מאגר הדחיסה.

ביישום המוקדם של Windows 10 מאגר הדחיסה נספר בתוך Working Set של תהליך System, אבל ב-Windows הנוכחי הוא מופיע ברשימות תהליכים של המנפה כתהליך Memory Compression ייעודי. לכן כשבודקים את כמות הדחיסה הנוכחית אל תעקבו רק אחרי Working Set של תהליך System. המטרה עצמה — להשאיר יותר אפליקציות בזיכרון פיזי ולהקטין קלט/פלט דיסק — לא השתנתה.¹⁰¹¹

עם זאת זכרו את הנקודות הבאות.

• דפים דחוסים עדיין משתמשים ב-RAM
• לדחיסה ולפריסה יש עלות מעבד
• דחיסה לא מוחקת את הבטחת ה-Commit
• אין סדר קבוע «תמיד לדחוס, אחר כך קובץ ההחלפה»
• המדיניות משתנה לפי סוג הדף, הלחץ והיסטוריית הגישה

«בשימוש (דחוס)» במנהל המשימות לא אומר שהדחיסה רוקנה לגמרי את הזיכרון הפיזי. מאגר הדחיסה אינו תכונה שהופכת את קובץ ההחלפה למיותר; הוא מוסיף אפשרות שמשתמשת במעבד כדי להקטין קלט/פלט בין RAM לאחסון.

9. התפקיד האמיתי של קובץ ההחלפה

לקובץ ההחלפה יש לפחות שלושה תפקידים.

flowchart LR
    accTitle: שלושה תפקידים של קובץ ההחלפה
    accDescr: קובץ ההחלפה מרחיב את Commit Limit, נהיה מאגר גיבוי לדפים פרטיים ששונו ונגישים לעיתים רחוקות, ונהיה קולט ל-dump של קריסת מערכת
    pagefile["קובץ ההחלפה"] --> limit["הרחבת Commit Limit（מרווח בצד התקרה）"]
    pagefile --> backing["מאגר גיבוי לדפים פרטיים ששונו"]
    pagefile --> dump["קולט ל-dump של קריסת מערכת"]

איור 4: תפקיד קובץ ההחלפה אינו רק «RAM איטית». גם כשהשימוש הוא 0 הוא עדיין תומך בתקרה וב-dump.

9.1. הרחבת Commit Limit

Commit Limit של המערכת נקבע בערך לפי RAM ועוד סך כל קובצי ההחלפה. בלי קובץ החלפה, Commit Limit יורד לרמה קצת קטנה מ-RAM המותקן. כש-Commit Total מגיע לתקרה, Commit חדש נכשל ויכול להוביל לסיום לא תקין של אפליקציה או לבעיות מערכת.⁴

זה עניין אחר מ«כמה ג’יגה-בתים כתובים עכשיו ב-pagefile.sys». קובץ ההחלפה הוא גם מרווח בצד התקרה שתומך בהבטחת ה-Commit.

9.2. תמיכה בדפים פרטיים ששונו

אם דפים פרטיים ששונו ונגישים לעיתים רחוקות מגובים בקובץ ההחלפה, אפשר להוציא את הדפים הפיזיים האלה מ-RAM ולתת אותם לקוד ולנתונים שנעשה בהם שימוש תכוף.⁴ כיבוי קובץ ההחלפה מקטין את האפשרות להוציא דפים כאלה מ-RAM. אי אפשר פשוט לומר «זה מהיר כי אין הוצאה לקובץ».

9.3. תמיכה ב-dump של קריסת מערכת

כדי לייצר Memory.dmp בקריסת מערכת צריך קובץ החלפה או קובץ dump ייעודי שיכול לתמוך בשיטת ה-dump שבחרתם.² dump זיכרון מלא, dump זיכרון ליבה ו-dump זיכרון אוטומטי נבדלים בכמות הנדרשת.

בסביבה שחוקרת קריסות, מחיקת קובץ ההחלפה רק כדי לחסוך מקום יכולה לומר שהראיות חסרות כשצריך אותן ביותר. לשיטות איסוף ראו גם «מבוא לאיסוף crash dump ב-Windows - WER,‏ ProcDump,‏ WinDbg».

10. הגודל הנכון אינו אחיד

אין להחליט על גודל קובץ ההחלפה מנוסחה קבועה כמו «פי 1.5 מ-RAM» לבדה. Microsoft מסבירה שהגודל המתאים שונה לכל מערכת בשתי הנקודות הבאות ואי אפשר להכליל.²

1. שיא System Commit Charge
2. dump קריסת המערכת שאתם צריכים

בפועל, חשבו בסדר הבא.

10.1. להתחיל מניהול המערכת כבסיס

ברירת המחדל של Windows היא ניהול המערכת. הוא גדל וקטן לפי RAM מותקן, ביקוש Commit, דרישות dump של קריסה וכדומה. בלי אילוץ מיוחד או תוצאת מדידה, להתחיל מכאן הוא הבחירה הבטוחה.

10.2. למדוד שיא Commit בעומס מייצג

אספו את המונים הבאים ב-PerfMon לאורך זמן ארוך.

• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\% Committed Bytes In Use
• Memory\\Modified Page List Bytes
• Paging File(*)\\% Usage
• Memory\\Available MBytes
• Memory\\Page Reads/sec
• Memory\\Page Writes/sec

כללו שיאים אמיתיים בתקופת האיסוף — עיבוד סוף חודש, גיבויים, בניות, כמה משתמשים יחד וכן הלאה.

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

10.3. להחליט קודם על דרישת ה-dump

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

11. לראות בעצמכם

11.1. להסתכל על רשימות דפים ב-RAMMap

הפעילו RAMMap כמנהל ופתחו קודם Use Counts.⁷ הפריטים להסתכלות הם הבאים.

• Active
• Standby
• Modified
• Modified no write
• Free
• Zeroed

Priority Summary מאפשר לאשר ש-Standby מחולק לפי עדיפות. Processes מציג את Working Set של כל תהליך; File Summary ו-File Details מאפשרים לעקוב אחרי נתוני קבצים שנמצאים ב-RAM.

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

שימו לב שתפריט Empty של RAMMap משנה את מצב המערכת באופן מלאכותי. אל תנקו Standby כשיפור ביצועים בייצור; השתמשו בו רק בסביבת בדיקה מבודדת.

11.2. להפריד Commit ו-Touch עם Testlimit

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

.\\testlimit64.exe -?

הבא מכוון ל-Testlimit v5.24. בתחביר הרשמי של v5.24, -m [MB] מקצה את כמות הזיכרון שצוינה, -d [MB] מקצה ו-Touch, -e [seconds] הוא מרווח ההקצאה, ו--c [count] הוא מספר ההקצאות. ציינו -c אחרון. אם מה שאתם רואים מקומית שונה, העדיפו את השימוש ההוא.¹²

אחר כך נסו בקטן על מכונה וירטואלית חד-פעמית.

# -m 64: הקצאת 64 MiB, -e 1: מרווח של שנייה, -c 8: עצירה אחרי 8 פעמים
.\\testlimit64.exe -m 64 -e 1 -c 8

# אותו מספר ואותו מרווח, עם -d כדי שכל אזור יקבל Touch
.\\testlimit64.exe -d 64 -e 1 -c 8

בזמן ההרצה רשמו באותו זמן את הבא.

• «מחויב X/Y» במנהל המשימות
• Active, Modified ו-Standby ב-RAMMap
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

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

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

12.1. «Standby גבוה, אז זו דליפת זיכרון»

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

12.2. «חיתוך Working Set יתקן את הדליפה»

גיזום משנה רק תושבות; הוא לא משחרר Commit או הקצאה וירטואלית. בגישה חוזרת הדף חוזר בשגיאה.

12.3. «השימוש בקובץ ההחלפה הוא 0, אז הוא מיותר»

קובץ ההחלפה תומך לא רק בכמות הכתיבה הנוכחית אלא גם ב-Commit Limit וב-dump של קריסה. להחליט למחוק אותו רק מהשימוש היומיומי מאבד מרווח בשיא וראיות ברגע הכשל.

12.4. «קודם דחיסת זיכרון, אחר כך תמיד קובץ ההחלפה»

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

13. סיכום

• מסד PFN הוא ספר החשבונות שעוקב אחרי בעלות, הפניות, שינוי ומצב רשימת דפים של דף פיזי.
• דף נקי שיוצא מ-Working Set נשאר ב-Standby ויכול לחזור בשגיאה רכה אם צריך את אותו תוכן.⁸
• דף מלוכלך מחכה ב-Modified ונכתב לקובץ ההחלפה אם הוא פרטי, או לקובץ המתאים אם הוא ממופה, וכן הלאה.³
• Available הוא סכום Standby, Free ו-Zeroed; Standby גדול לבדו אינו מחסור בזיכרון.¹
• דחיסת זיכרון דוחסת דפים ב-RAM כדי להקטין קלט/פלט, אבל לא מוחקת את תפקידי Commit וקובץ ההחלפה.¹⁰
• קובץ ההחלפה תומך ב-Commit Limit, בדפים פרטיים ששונו וב-dump של קריסת מערכת.⁴²
• הגודל המתאים נקבע לפי שיא Commit ודרישות dump; אי אפשר להחליט עליו במכפיל אחיד.²
• גיזום Working Set וניקוי Standby אינם תיקון דליפת זיכרון.

ההמשך בחלק 3, «אובייקטי מקטע והעתקה בכתיבה: מה באמת DLL ומיפויי קבצים».

אנחנו עוקבים למה דפי קבצים ו-DLL שנשארים ב-Standby נראים מכמה תהליכים כאותו דף פיזי.

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

• מעמקי זיכרון Windows (חלק 1) — הרגע שבו כתובת וירטואלית הופכת ל-RAM פיזית
• What Does Windows’ “Memory Usage” Actually Mean? — Correctly Reading Working Set, Private Bytes, Commit, and the Page File
• The Depths of Windows I/O (Part 4) — Cache Manager: When Does Your WriteFile Actually Reach the Disk?
• מבוא לאיסוף crash dump ב-Windows - WER,‏ ProcDump,‏ WinDbg
• Process Explorer / Handle / VMMap in Practice — Chasing Hangs, Leaks, and “File in Use” from the State Right Now

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

KomuraSoft LLC מטפלת בחקירות של לחץ זיכרון באפליקציות Windows, מיצוי Commit, עימוד, גידול Working Set ותכנון איסוף dump של קריסה.

• פיתוח יישומי Windows
• חקירת תקלות ואיתור גורמים
• שימוש חוזר והעברה של נכסים קיימים
• צרו קשר

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

האם דף נכתב לקובץ ההחלפה ברגע שהוא יוצא מ-Working Set?

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

האם הזיכרון הזמין במנהל המשימות כולל זיכרון Standby?

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

האם הכתיבה לקובץ ההחלפה מתחילה רק אחרי ש-RAM נגמר לגמרי?

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

האם כיבוי קובץ ההחלפה מאיץ את Windows?

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

אם יש דחיסת זיכרון, האם קובץ ההחלפה מיותר?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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