מנגנון הזיכרון של Windows (חלק 2) — מחזור החיים של דף פיזי: חמש רשימות והאמת על ה-pagefile

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

לעיתים מסבירים את זה במשפט אחד: “הדף עובר page-out ל-pagefile”. בפועל יש כמה מצבים לפני ואחרי. דף שלא שונה יכול לעבור ל-Standby ולהשאיר את התוכן במקום. דף ששונה מחכה קודם ל-write-back ב-Modified. ב-reuse הוא עשוי לעבור ב-Free או ב-Zeroed, ואם צריך שוב את אותו תוכן הוא יכול לחזור מ-Standby ב-soft fault.

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

סדרת “מנגנון הזיכרון של Windows” — שלושת החלקים

1. חלק 1: כתובות וירטואליות ו-Page Fault
   אנחנו עוקבים מתי דף וירטואלי שעבר Commit מקבל RAM פיזי.
2. חלק 2 (המאמר הזה): מחזור החיים של דף פיזי
   אנחנו עוקבים אחרי מעברי מצב של דף שיוצא מ-Working Set, ואחרי תפקיד ה-pagefile.
3. חלק 3: section objects ו-copy-on-write
   אנחנו עוקבים אחרי המנגנון שבו DLL, file mapping וזיכרון משותף חולקים דפים פיזיים.

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

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

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

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

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

• דף שיוצא מ-Working Set לא בהכרח נעלם מיד.
  דף clean נשאר ב-Standby ויכול לחזור בלי לקרוא דיסק אם צריך את אותו תוכן.
• דף ששונה אי אפשר לעשות בו reuse מיד.
  תוכן private נהיה ל-reuse אחרי שאפשר לכתוב אותו ל-pagefile; mapped file, אחרי שאפשר לכתוב אותו לקובץ המתאים; וכן הלאה.
• Available כולל Standby.
  Standby הוא cache שעדיין מחזיק תוכן, ובאותו זמן מועמד ל-reuse שאפשר לקחת מיד אם צריך.¹
• הכתיבה ל-pagefile אינה משימה באצווה שמתחילה רק אחרי ש-RAM נגמר לגמרי.
  היא מתקדמת ברקע לפי רשימת Modified ולחץ הזיכרון.²³
• ה-pagefile אינו רק “RAM איטית”.
  הוא מרחיב את Commit Limit, נהיה backing store לדפים private ששונו, ותומך ב-crash dump.⁴
• כיבוי ה-pagefile לא מתקן memory leak.
  Commit Limit יורד, ואפשר לאבד אפשרויות לשימוש יעיל ב-RAM ואת היכולת לאסוף dump.

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

2. PFN database — ה-ledger בצד ה-RAM הפיזי

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

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

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

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

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

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

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

flowchart LR
    zeroed["Zeroed\nמאופס"] -->|Touch ראשון| active["Active / Valid\nreferenced מ-Working Set"]
    active -->|trim של clean| standby["Standby\nמועמד ל-reuse עם תוכן"]
    active -->|trim של dirty| modified["Modified\nממתין ל-write-back"]
    modified -->|ה-write-back הסתיים| standby
    standby -->|חזרה ב-soft fault| active
    standby -->|discard של הזהות הישנה| free["Free\nלא מאופס"]
    standby -->|reuse ישיר לייעוד אחר| active
    free -->|להקצאה שדורשת אפסים| zeroed

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

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

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

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

4.1. trim אינו שחרור

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

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

הפעלת EmptyWorkingSet או “Trim Working Set” של כלי אינה תחליף ל-VirtualFree או שחרור heap. אם נוגעים שוב באותו דף, הוא חוזר ב-soft fault מ-Standby או ב-hard fault מ-backing store. לכן “הקטנתי את Working Set” לא אומר “תיקנתי את ה-leak”.

5. דף clean הולך ל-Standby

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

• קוד EXE/DLL שלא שונה
• memory-mapped file שלא שונה
• דף private שכבר נכתב בחזרה
• נתונים שנשארו ב-file cache

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

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

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

5.1. למה Available כולל Standby

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

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

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

לכן אין סתירה כש-Task Manager מציג “Free נמוך, אבל Cached/Standby גבוה ו-Available מספיק”. Windows לא משאיר RAM פנוי סתם כך; הוא משאיר ב-Standby קבצים וקוד שהיו בשימוש לאחרונה, כדי שאפשר יהיה לעשות בהם reuse מהר כ-cache אם צריך, ולוקח אותם אם ייעוד אחר צריך אותם.

אל תסיקו “Free נמוך, אז חסר לנו זיכרון מיד”; הסתכלו יחד על Available, Commit, hard fault ועיכוב עיבוד.

6. דף dirty מחכה ב-Modified

כשאפליקציה כותבת לדף, התוכן כבר לא תואם ל-backing store המקורי. דריסת הדף ה-dirty הזה לייעוד אחר תאבד את הנתונים. לכן דף ששונה והוסר מ-Working Set מחכה ל-write-back ב-Modified.

יעד ה-write-back תלוי בסוג הדף.

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

6.1. Modified Page Writer

Modified Page Writer הוא system worker visסורק דפים dirty עם backing ב-pagefile שה-memory manager עוקב אחריהם, וכותב אותם ל-pagefile.³ בצד ה-mapped file יש נתיבים כמו Mapped Page Writer שמשתפים פעולה עם מערכת הקבצים ו-Cache Manager כדי לעשות write-back לקובץ המתאים.

הנקודה החשובה היא שהכתיבה אינה סכמה של “לא לעשות כלום עד ש-RAM הוא 0 בתים”. Windows מכין ברקע דפים שאפשר יהיה לעשות בהם reuse בעתיד, לפי רשימת Modified, Available, מצב ה-pagefile וגורמים דומים. כשה-write-back מסתיים ואין הפניות תקפות אחרות, הדף מתקדם ל-Standby עם התוכן שלו.

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

איור 3: יעד ה-write-back נקבע לפי סוג הדף, ושני הנתיבים מתקדמים ברקע. במערכת שבה ה-pagefile כבוי אין יעד write-back בצד הדף ה-private, ולכן דפים private ששונו נשארים ב-RAM.

6.2. להפריד page output מ-I/O ספציפי ל-pagefile

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

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

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

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

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

7.1. Standby

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

• אם צריך את אותו תוכן, הוא יכול לחזור ב-soft fault
• אם ייעוד אחר צריך אותו, אפשר לעשות discard לזהות הישנה ולעשות reuse
• יש רשימות Standby לפי עדיפות

7.2. Free

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

7.3. Zeroed

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

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

8. compression store — ליצור עוד יעד בתוך RAM

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

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

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

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

“בשימוש (דחוס)” ב-Task Manager לא אומר שהדחיסה רוקנה לגמרי את הזיכרון הפיזי. ה-compression store אינו תכונה שהופכת את ה-pagefile למיותר; הוא מוסיף אפשרות שמשתמשת ב-CPU כדי להקטין I/O בין RAM ל-storage.

9. התפקיד האמיתי של ה-pagefile

ל-pagefile יש לפחות שלושה תפקידים.

flowchart LR
    accTitle: שלושה תפקידים של ה-pagefile
    accDescr: ה-pagefile מרחיב את Commit Limit, נהיה backing store לדפים private ששונו ונגישים לעיתים רחוקות, ונהיה יעד ל-crash dump של המערכת
    pagefile["pagefile"] --> limit["הרחבת Commit Limit (headroom בצד התקרה)"]
    pagefile --> backing["backing store לדפים private ששונו"]
    pagefile --> dump["יעד ל-crash dump של המערכת"]

איור 4: תפקיד ה-pagefile אינו רק “RAM איטית”. גם כשהשימוש הוא 0 הוא עדיין תומך בתקרה וב-dump.

9.1. הרחבת Commit Limit

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

זה עניין אחר מ”כמה GB כתובים עכשיו ב-pagefile.sys”. ה-pagefile הוא גם headroom בצד התקרה שתומך ב-Commit.

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

אם דפים private ששונו ונגישים לעיתים רחוקות מגובים ב-pagefile, אפשר להוציא את הדפים הפיזיים האלה מ-RAM ולתת אותם לקוד ולנתונים שנעשה בהם שימוש תכוף.⁴ כיבוי ה-pagefile מקטין את האפשרות להוציא דפים כאלה מ-RAM. אי אפשר פשוט לומר “זה מהיר כי אין page-out”.

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

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

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

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

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

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

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

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

ברירת המחדל של Windows היא ניהול המערכת. הוא גדל וקטן לפי RAM מותקן, ביקוש Commit, דרישות crash 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

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

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

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

החליטו אם צריך dump זיכרון מלא, אם dump זיכרון kernel מספיק, או אם תשתמשו בקובץ 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. קריאה חוזרת של אותו קובץ יכולה לשחזר דפים שעוד לא נעשה בהם reuse בלי I/O דיסק, או עם מעט. התוצאות משתנות לפי לחץ זיכרון, אנטי-וירוס וגודל הקובץ, לכן הסתכלו על כיוון מעבר המצב ולא על סט מספרים אחד.

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

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

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

.\\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

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

• “Committed X/Y” ב-Task Manager
• Active, Modified ו-Standby ב-RAMMap
• Memory\\Committed Bytes
• Memory\\Commit Limit
• Memory\\Available MBytes
• Memory\\Modified Page List Bytes

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

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

12.1. “Standby גבוה, אז זו memory leak”

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

12.2. “trim של Working Set יתקן את ה-leak”

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

12.3. “השימוש ב-pagefile הוא 0, אז הוא מיותר”

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

12.4. “קודם דחיסת זיכרון, אחר כך תמיד pagefile”

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

13. סיכום

• ה-PFN database הוא ה-ledger שעוקב אחרי בעלות, הפניות, שינוי ומצב רשימת דפים של דף פיזי.
• דף clean שיוצא מ-Working Set נשאר ב-Standby ויכול לחזור ב-soft fault אם צריך את אותו תוכן.⁸
• דף dirty מחכה ב-Modified ונכתב ל-pagefile אם הוא private, או לקובץ המתאים אם הוא mapped, וכן הלאה.³
• Available הוא סכום Standby, Free ו-Zeroed; Standby גדול לבדו אינו מחסור בזיכרון.¹
• דחיסת זיכרון דוחסת דפים ב-RAM כדי להקטין I/O, אבל לא מוחקת את תפקידי Commit וה-pagefile.¹⁰
• ה-pagefile תומך ב-Commit Limit, בדפים private ששונו וב-crash dump של המערכת.⁴²
• הגודל המתאים נקבע לפי שיא Commit ודרישות dump; אי אפשר להחליט עליו במכפיל אחיד.²
• trim של Working Set וניקוי Standby אינם תיקון memory leak.

ההמשך בחלק 3, “section objects ו-copy-on-write: מה באמת DLL ו-file mapping”.

אנחנו עוקבים למה דפי קבצים ו-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, exhaustion של Commit, paging, גידול Working Set ותכנון איסוף crash dump.

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

קישורים

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

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

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

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

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

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

שאלות נפוצות

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

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

לא. דף clean (שלא שונה) עובר ל-Standby עם התוכן שלו והופך ל-cache שאפשר לעשות בו reuse מיד. דף dirty (ששונה) עובר ל-Modified, ואחרי write-back לפי הצורך ל-pagefile או לקובץ המתאים הוא מתקדם למצב שאפשר לעשות בו reuse, כמו Standby.

האם הזיכרון Available ב-Task Manager כולל זיכרון Standby?

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

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

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

האם כיבוי ה-pagefile מאיץ את Windows?

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

אם יש דחיסת זיכרון, האם ה-pagefile מיותר?

הוא לא נעשה מיותר. compression store דוחס דפים ב-RAM כדי להקטין I/O, אבל דפים דחוסים עדיין משתמשים בזיכרון פיזי ואינם מחליפים את ה-Commit. הבחירה בין דחיסה ל-page-out היא מדיניות דינמית של ה-memory manager.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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