פתרון קבוצת עבודה ולחץ זיכרון

אחרי trimming עדיין קיימת אותה הקצאה ואותם ערכים. ה־faults בסריקה החוזרת יכולים להיות soft faults אם התוכן עדיין נמצא במצב זיכרון מתאים, ולכן אין להסיק שכל עלייה במונה מייצגת גישה לדיסק.

ה־private commit מתאר התחייבות שאינה נעלמת רק משום שהדפים אינם תושבים כרגע ב־working set. גם cache יישומי יכול לשמור הקצאות בכוונה. כדי להבדיל, בודקים את מספר האובייקטים וה־bytes שהיישום עדיין מחזיק ואת מדיניות הפינוי.

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

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

const auto pages_touched =
    (size + static_cast<SIZE_T>(info.dwPageSize) - 1) / info.dwPageSize;
if (sum != 11ull * pages_touched) {
    VirtualFree(memory, 0, MEM_RELEASE);
    return 3;
}

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

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

הדוח צריך לכלול את תנאי המערכת ואת השונות בין ריצות. תוצאה בודדת אינה מאפשרת להכריע אם דחיסה, standby, pagefile או תחרות על CPU היו הגורם הדומיננטי.