Jeśli użyję następującego wywołania w C ++, spodziewałbym się, że WorkingSet procesu nigdy nie spadnie poniżej 100 MB.

Jednak system operacyjny nadal przycina zestaw roboczy z powrotem do 16 MB, nawet jeśli wykonam to połączenie.

Ustawienie WorkingSet na 100 MB doprowadziłoby do dramatycznego wzrostu prędkości mojej aplikacji, eliminując błędy stronicowania stron (patrz diagram poniżej).

Co ja robię źle?

SIZE_T workingSetSizeMB = 100;
int errorCode = SetProcessWorkingSetSizeEx(
    GetCurrentProcess(),
    (workingSetSizeMB - 1) * 1024 * 1024), // dwMinimumWorkingSetSize
    workingSetSizeMB * 1024 * 1024,  // dwMaximumWorkingSetSize,
    QUOTA_LIMITS_HARDWS_MIN_ENABLE | QUOTA_LIMITS_HARDWS_MAX_DISABLE
  );
// errorCode returns 1, so the call worked.

(dodatkowe dla ekspertów) Metodologia eksperymentalna

Napisałem testowy projekt C ++, aby przydzielić 100 MB danych, aby przełączyć WorkingSet na ponad 100 MB (w widoku Process Explorer), a następnie zwolnić tę pamięć. System operacyjny przywrócił jednak WorkingSet do 16 MB, gdy tylko zwolniłem tę pamięć. Mogę dostarczyć testowy projekt C ++, którego użyłem, jeśli chcesz.

Dlaczego system Windows wywołuje funkcję SetProcessWorkingSetSizeEx (), jeśli nie działa? Muszę coś zrobić źle.

Poniższy diagram pokazuje dramatyczny wzrost liczby błędów stronicowania (czerwone skoki), gdy zielona linia (zestaw roboczy) spadła z 50 MB do 30 MB.

Aktualizacja

Ostatecznie skończyło się na ignorowaniu problemu, ponieważ nie wpłynęło to na wydajność.

Co ważniejsze, SetProcessWorkingSetSizeEx działanie kontroluj aktualny WorkingSet i jestnie w jakikolwiek sposób związane z miękkimi błędami stron. Jedyne, co robi, to zapobieganie awariom stron, zapobiegając przenoszeniu bieżącego WorkSet na dysk twardy.

Innymi słowy, jeśli chcemy zmniejszyć błędy stron miękkich, SetProcessWorkingSetSizeEx nie ma żadnego efektu, ponieważ odnosi się do twardych błędów stron.

W „Windows via C / C ++” (Richter) jest świetny zapis, w jaki sposób Windows radzi sobie z pamięcią.