Re: Optymalizacja WindowsXP pod katem 4GB RAMu

Wiktor S. napisał(a):
> Zakładając jednak, że pamięci mamy bardzo dużo, exe będą zawsze w
> pamięci, a pliki z danymi zrzucane tylko w wyniku jawnego zapisu.
> W takich warunkach plik wymiany nie powinien być w ogóle używany...

Ale takie warunki nigdy nie zachodzą.

Windows dla każdego procesu wylicza minimalny i maksymalny
rozmiar zestawu roboczego (na podstawie ilości pamięci
fizycznej). Program może zmienić te wartości, ale praktycz-
nie *żaden* znany mi (poza AutoCADem 2004) tego nie robi.
W pierwszym planie ten limit może być poważnie nagięty,
jednak gdy aplikacja przechodzi w drugi plan, system stara
się zbić rozmiar zestawu roboczego do wyliczonego minimum,
by nowa aplikacja pierwszoplanowa miała jak najwięcej
wolnego "placu" w RAMie.

Nie trzeba wcale do tego jakichś specjalnych wymagań
dotyczących pamięci. Wystarczą operacje na plikach lub
jakaś drobna alokacja. Każda zmiana stanu pamięci fizycznej
powoduje wymiecenie po parę stron z każdego procesu co
ileś tam sekund.

Dopóki przełączasz się często między aplikacjami, nie ma
problemu. Tempo redukcji zestawu roboczego jest nieduże,
a do tego strony nie są bezwarunkowo wymiatane, a umiesz-
czane na osobnej liście "gotowych do usunięcia" (nieak-
tywnych). Gdy zatem proces na powrót staje się aktywny,
jego zestaw roboczy znów może rosnąć, a operacje page-in
dla stron, które znów są potrzebne - choć wprowadzają
pewien narzut - powodują tylko przeniesienie stron z
powrotem do listy stron aktywnych, bez komunikacji z
dyskami.

Gorzej, gdy pracujesz długo z intensywnie zarządzającą
pamięcią aplikacją. Po przełączeniu na inną zestaw roboczy
może być tak ograniczony, że wiele operacji będzie skutko-
wało drobniejszym lub poważniejszym "grzebaniem" po dysku.
Oczywiście po chwili wszystko wróci do normy, ale wcale nie
musi być za mało RAMu, by takie coś się działo.

Najgorzej jest jednak, gdy minimalizujesz okno programu.
Uruchamia się wtedy mechanizm, który w czasach Windows NT
3.1 i 3.5 pozwalał pracować w systemie nawet na 8 czy 16 MiB
pamięci, ale dzisiaj przy 512 czy 1024 MiB bardziej szkodzi
niż pomaga. System w takiej sytuacji *natychmiast* minimalizuje
zestaw roboczy aplikacji zakładając, że nie potrzebujesz tego
programu przez dłuższy czas, skoro go minimalizujesz. W efekcie
strony są natychmiast znaczone jako nieaktywne i po co
najwyżej paru minutach usuwane z RAMu.

Wniosek: nie można być pewnym braku swapowania mimo braku
pliku wymiany i posiadania dużej ilości RAMu, a plik wymiany
jest używany praktycznie zawsze, jak już w ogóle istnieje.

W Viście zmieniono nieco zachowanie menedżera pamięci, stara
się on mniej swapować kosztem aplikacji pierwszoplanowych
(większe równouprawnienie programów). Zlikwidowano też chyba
to opróżnianie zestawu roboczego przy minimalizacji okna.
Szczegółów nie podam, bo za mało z Vistą pracowałem i za mało
jest jeszcze materiałów opisujących jej jądro.

Na temat zestawu roboczego w Windows polecam mój cykl blogu:
http://www.grush.one.pl/blog.php?month=2006-08&id=408

-- 
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół  |  http://www.grush.one.pl/              |
|                 |  Administrator, Politechnika Śląska    |
\................... Microsoft MVP ......................../