Re: Tzw. "uzycie pliku stron"...

Autor: Paweł Goleń <p_golen_at_ks.onet.pl>
Data: Fri 10 Jun 2005 - 14:56:09 MET DST
Message-ID: <d8c2uo$spn$1@nemesis.news.tpi.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed

Radosław Sokół wrote:
> A system odwołuje się do pliku wymiany, bo każdy program
> sam określa ile jego kodu i danych powinno być trzymane
> w pamięci. Gdy ten limit zostanie przekroczony, przy byle
> okazji (np. przy powiększaniu cache dysku) nadmiar zostaje
> wyrzucony do pliku wymiany nawet, jeśli fizycznego RAMu
> jest sporo wolnego).

No nie do końca mogę się z Tobą zgodzić Radku (a znaczna część posta
jest odpowiedzią dla pytającego). Po części masz rację, ale prawda jest
taka, że 99% ze standardowych wartości WorkingSet. Ładnie pokazuje to na
przykład wspominany już debugger dla Windows. Wartości graniczne
WorkingSet nie są bynajmniej sztywne, dla przykładu Thunderbird:

lkd> !process 0fa4
Searching for Process with Cid == fa4
PROCESS 833347b8 SessionId: 0 Cid: 0fa4 Peb: 7ffdd000 ParentCid: 022c
     DirBase: 04a02000 ObjectTable: e1c07e00 HandleCount: 183.
     Image: thunderbird.exe
     VadRoot 82fbf838 Vads 130 Clone 0 Private 6218. Modified 445. Locked 0.
     DeviceMap e1888570
     Token e1c16600
     ElapsedTime 00:04:54.349
     UserTime 00:00:11.246
     KernelTime 00:00:03.424
     QuotaPoolUsage[PagedPool] 53108
     QuotaPoolUsage[NonPagedPool] 8672
     Working Set Sizes (now,min,max) (8945, 50, 345) (35780KB, 200KB,
1380KB)
     PeakWorkingSetSize 9157
     VirtualSize 95 Mb
     PeakVirtualSize 100 Mb
     PageFaultCount 14562
     MemoryPriority BACKGROUND
     BasePriority 8
     CommitCharge 6597

Jak widzisz obecna wartość Working Set znacznie przekracza wartość max.
Natomiast gdy zminimalizuję Thunderbirda:

  Working Set Sizes (now,min,max) (260, 50, 345) (1040KB, 200KB, 1380KB)

Jak widać zmiana jest znaczna. Nie oznacza to, że te 34MiB pamięci
zostały przerzucone od razu do swap, trafiły na listę standby, która
jest powoli przerzucana do pliku wymiany. W przypadku, gdy
zmaksymalizuję Thunderbirda, to Working Set ponownie wzrośnie:

Working Set Sizes (now,min,max) (5463, 50, 345) (21852KB, 200KB, 1380KB)

Nie oznacza to jednak, że te 20MiB pamięci było wczytywane z dysku.
Jeśli żadna inna aplikacja nie poprosiła o pamięć i system nie
przydzielił jej tych stron, które były wykorzystywane przez
Thunderbirda, proces dostanie swoje "stare" strony. W przeciwnym
przypadku system musiałby wczytać stosowne strony z pliku wymiany.

A co by się stało, gdyby inny proces potrzebował pamięci (zwróć uwagę,
że teraz mam mało pamięci na liście Zeroed, reszta jest na liście
Standby. Pamięć, która jest "czysta", czyli nie została zmieniona od
czasu zapisania stron do pliku wymiany może zostać od razu przyznana
aplikacji, która ją potrzebuje (w praktyce pamięć ta musi być wcześniej
wyzerowana, patrz lista Zeroed).

A teraz popatrzmy na linuksa. System nie używa swap do czasu, do kiedy
ma pamięć. Powiedzmy, że jest wydajniej (powiedzmy, bo pamiętaj o tym co
pisałem o odzyskiwaniu pamięci z listy Standby). W pewnej chwili kończy
się pamięć i... i system musi skorzystać z pliku wymiany. W efekcie
następuje mocne swappowanie, które zbiega się z uruchamianiem programu,
może wówczas powstać dość spore obciążenie I/O, bo linuks stara się w
jednej chwili zrobić to, co Windows robi sukcesywnie co kilka sekund.
Zresztą zachowanie linuksa bywa różne, w zależności od tego, czy jest to
kernel z -mm czy bez :)

Reasumując, nie jest prawdą, że Windows nie potrafi wykorzystać w pełni
dostępnej pamięci. To, co widzisz jako free tak na prawdę wcale free nie
jest :)

-- 
Paweł Goleń
mailto:p_golen@ks.onet.pl
"Wszyscy przecież wiemy, że nikt nie dostaje żadnych spamów" - mój trol
UGVybCBTVUNLUw==
Received on Fri Jun 10 15:00:23 2005

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Fri 10 Jun 2005 - 15:42:05 MET DST