Stronicowanie Windows – wyniki optymalizacji

Tutaj zastosowałem nieco inny test niż wcześniej, mianowicie uważni czytelnicy zaobserwowali, że zapychałem pamięć danymi, które zmieniły się od momentu uruchomienia ich. Tym razem postanowiłem uruchomić maksymalnie dużo aplikacji, które się, że tak powiem nie zmieniają, czyli są to wszelkiego rodzaju aplety panelu sterownia, benchmarki, czy przeglądarka internetowa, w której otwierałem kilkanaście okien z bardzo dużymi plikami.

Zrzut ekranu nr 13:

Obserwacje:

Tabela nr 13:

 
Tabela procesów nr 13:

Wnioski faza 1:

1. Sprawdza się to o czym pisałem w artykule o Stronicowaniu – wszelkie dane, które się zmieniają automatycznie znajdują się w pliku pagefile.sys – widać to ewidentnie w programie coreldrw.exe gdzie licznik PF Delta wskazywał aż 23.
2. Sumując kolumnę Mem Usage i VM Size otrzymujemy wartość równą 237 156 KB – czyli definicja podana na początku zgadzałaby się.
3. System nie wykazuje przypadłości związanych z używaniem swapa.

Wnioski faza 2:

1. Zgodnie z przypuszczeniami zajętość pamięci rośnie i to dość szybko.
2. W większości przypadków aplikacje nie używane zajmują nieco mniej pamięci.
3. Sumując Mem Usage i VM Size otrzymujemy wartość równą 339 444 KB – podobnie jak we wnioskach z fazy nr 1 – definicja podana na początku pasuje do naszych obserwacji.
4. Zaczyna się odczuwać używanie swapa.

Wnioski faza 3:

1. Podobnie jak wyżej zajętość pamięci rośnie, a przynajmniej wskaźnik pokazywany w pasku statusu menadżera zadań.
2. Wskaźnik Mem Usage wzrósł bardzo nieznacznie, można powiedzieć, że w granicach błędu.
3. Wskaźnik VM Size urósł już więcej.
4. Programy: MS Word, explorer, IE, Menadżer zadań, Total CMD oraz WP Kontakt nie zmieniły swojego zapotrzebowania na pamięć w stopniu wartym odnotowania.
5. Macromedia Firewoks była aplikacją, która była odpowiedzialna za wzrost zajętości pamięci. Wzrost odnotowałem zarówno w kolumnie Mem Usage jak i VM Size.
6. Corel Draw schudnął jednak tylko w kolumnie Mem Usage.
7. Użycie swapa już mocno czuć.

Wnioski faza 4:

1. Mamy dalszą ciągłość wzrostu zajętości pamięci wykazywanej w pasku statusu.
2. Po raz kolejny wskaźnik Menory usage urósł bardzo nieznacznie.
3. Za to przyrost jest widoczny w kolumnie VM Size.
4. Programy: MS Word, explorer, IE, Menadżer zadań, Total CMD oraz WP Kontakt nie zmieniły swojego zapotrzebowania na pamięć w stopniu wartym odnotowania.
5. Tym razem Fireworks urósł zarówno w Mem Usage jak i VM Size.
6. Corel Draw schudnął w Mem Usage a za to urósł w VM Size.
7. Będziemy już chyba pomijali ten punkt w dalszych wnioskach 🙂

Wnioski faza 5:

1. Mamy dalszą ciągłość wzrostu zajętości pamięci wykazywanej w pasku statusu.
2. Po raz pierwszy wskaźnik Mem Usage spadł, nieznacząco, ale spadł.
3. Zgodnie z oczekiwaniami VM Size urósł.
4. Do grona aplikacji „nieruszonych” możemy teraz zaliczyć jedynie: MS Word, Explorer, Corel Draw.
5. Za to aplikacje Total CMD, Internet Explorer oraz WP Kontakt zmieniły dość drastycznie swoje zapotrzebowanie na pamięć. Kolumna Mem Usage w ich wypadku można powiedzieć została podzielona na pół, co ciekawe VM Size w przypadku tych programów pozostało na tym samym poziomie.
6. Fireworks tradycyjnie już puchnie tu i tu.

Wnioski faza 6:

1. Mamy dalszą ciągłość wzrostu zajętości pamięci wykazywanej w pasku statusu.
2. Po raz kolejny wskaźnik Menory usage urósł bardzo nieznacznie, choć i tak jest niżej niż w fazie nr 4.
3. Zgodnie z oczekiwaniami VM Size urósł.
4. Wnioski podsumować można jednym stwierdzeniem: Jedynie co puchnie to Fireworks, reszta pozostała bez zmian.

Wnioski faza 7:

1. Mamy dalszą ciągłość wzrostu zajętości pamięci wykazywanej w pasku statusu.
2. Po raz kolejny obserwujemy spadek wskazań Mem Usage, tym razem różnice widać gołym okiem.
3. Zgodnie z oczekiwaniami VM Size urósł.
4. Do grona aplikacji „nieruszonych” możemy teraz zaliczyć jedynie: Explorer, Corel Draw.
5. Za to aplikacje Total CMD, Internet Explorer oraz WP Kontakt zmieniły swoje zapotrzebowanie na pamięć. Kolumna Mem Usage w ich wypadku spadła dość znacznie, choć różnice nie są tak spektakularne jak w przypadku fazy 5, co ciekawe VM Size w przypadku tych programów pozostało na tym samym poziomie.
6. Fireworks tradycyjnie już puchnie, ale tym razem tylko w VM Size.

Wnioski faza 8:

1. Mamy dalszą ciągłość wzrostu zajętości pamięci wykazywanej w pasku statusu.
2. Po raz kolejny obserwujemy spadek wskazań Mem Usage, tym razem różnice są już ogromne.
3. Zgodnie z oczekiwaniami VM Size urósł.
4. Zajętość w kolumnie Mem Usage drastycznie spadła dla większości aplikacji, bardzo łądnie to widać gdy te dwa screeny (nr 7 i nr8) otworzymy w przeglądarce grafik i zrobimy sobie mini Slide Show – myślę, że komentarz jest zbędny.
5. Fireworks tradycyjnie już puchnie, ale tym razem tylko w VM Size.

Wnioski faza 9:

1. Menadżer zadań wykazał dość znaczny spadek zajętości pamięci.
2. Po raz kolejny obserwujemy spadek wskazań Mem Usage, po raz kolejny różnice są ogromne.
3. Podobnie się ma sprawa w przypadku VM Size.
4. Niektóre programy nieco spuchły w kolumnie Mem Usage, niektóre po raz kolejny schudły.

Wnioski faza 10:

1. Menadżer zadań zasadniczo nie wykazał zmian w zajętości pamięci.
2. Obserwujemy wzrost zajętości w kolumnie Mem Usage – powód dość oczywisty, przywróciliśmy wszystkie aplikacje do pulpitu.
3. VM Size wzrosło bardzo nieznacznie, a spowodowane jest włączeniem Excela..
4. Niektóre programy spuchły w kolumnie Mem Usage..

Wnioski faza 11:

1. Oczekiwany wzrost zajętości pamięci.
2. Obserwujemy wzrost zajętości w kolumnie Mem Usage jak i VM Size.
3. Zarówno Corel jak i Fireworks mają bardzo duży udział w zajętośći pamięci w obydwu kolumnach.
4. Aplikacje nieużywane jak i wcześniej w podobnych przypadkach zaczynają chudnąć w kolumnie Mem Usage.

Wnioski faza 12:

1. Oczekiwany spadek zajętości pamięci.
2. Obserwujemy spadek zajętości w kolumnie Mem Usage jak i VM Size.
3. Zgodnie z oczekiwaniami Fireworks spuchł, a Corel zwolnił miejsce w obydwu kolumnach.
4. Aplikacje nieużywane jak i wcześniej w podobnych przypadkach zaczynają chudnąć w kolumnie Mem Usage.
5. Zamknięcie Corela nie spowodowało użycia przestrzeni przez niego zajmowanej przez inne aplikacje.

Wnioski faza 13:

1. Wzrost zajętości pamięci i to znaczny.
2. Wzrost sumy kolumny Mem Usage jak i VM Size.
3. Przyrost kolumn spowodowany jest głównie przeglądarką Internet Explorer.
4. Aplikacja Rundll32.exe, która odpala większość apletów zajmuje podobne wartości w Mem Usage jak i VM Size.
5. Niestety VM Size puchnie pomimo, tego iż włączyliśmy aplikacje, które nie zmieniły swojej zawartości od jej uruchomienia.

Wnioski ogólne
Wykres 1:

Powyższe obserwacje dla większości z was zapewne nie były zbyt przejrzyste, nie można też było w prosty sposób zaobserwować, co się tak naprawdę dzieje. Dlatego też postaram się to w jak najbardziej jasny sposób przedstawić teraz.

Załączony wykres jest podsumowaniem wszystkich 13 faz moich testów.

Przyjrzyjmy się dokładniej relacji użycia pamięci (Memory Usage) oraz wirtualnej pamięci (VM Size). Jak widać na załączonym wykresie dopiero w fazie 4 VM Size jest większy niż Memory Usage i tak też pozostanie do samego końca. Wniosek z tego jest jeden: nie można tych dwóch wartości bezpośrednio ze sobą wiązać. Wielkość pierwszej nie ma praktycznie żadnego związku z wielkością drugiej.

Kolejną rzeczą, jaką obserwujemy to Memory Usage nigdy nie przekroczyła bariery 200 MB, jest to dość dziwne zachowanie gdyż komputer oferował 256 MB, co się dzieje z pozostałymi 60 MB?

Zajętość pamięci była zawsze większa niż wielkość VM Size. Pozostawmy na razie tą kwestię otwartą, później myślę, że uda się ją rozwiązać.

Przypomnijmy sobie dokładnie etapy naszego testu.

• Od etapu pierwszego aż do ósmego zapychaliśmy pamięć, poprzez robienie kolejnych zrzutów ekranu.
• W kroku 9 wyłączyliśmy dwa programy graficzne (najbardziej zajmujące pamięć) oraz komunikator internetowy (WP Kontakt).
• W kroku 10 zamknąłem ogromny dokument Worda, choć inny, w którym pisałem pozostał, otwarłem Excela, przywróciłem wszystkie aplikacje z tła.
• Faza 11 polegała na otwarciu po raz kolejny Corela i załadowaniu do niego kilku dużych map bitowych. Był już włączony Fireworks, który zapisał już zrzut ekranu z poprzedniej fazy.
• W 12-tce zamknęliśmy Corela.
• Krok 13 był inny niż wszystkie: wyłączone zostały programy graficzne, ale za to włączyłem wszystkie aplety panelu sterowania, dużą ilość aplikacji z Menu Start, które nie służyły edycji danych, tylko ich wykonywaniu, generalnie chodziło o załadowanie do pamięci dużej ilości danych, które się nie zmieniły od czasu ich załadowania. Otwarłem również bardzo duże pliki html w przeglądarce Internet Explorer.

Przyglądnijmy się ponownie wykresowi. Zaobserwować można dość ciekawe zachowanie systemu. VM Size generalnie zachowuje się zgodnie z naszymi oczekiwaniami, czyli od 1-8 rośnie, w 9 spada, w 10 zapewne z powodu Excela nieco urósł, nie zaskoczył nas też i w kolejnych krokach. Natomiast Memory Usage zachowuje się dość nietypowo, a przynajmniej inaczej niż VM Size. Do kroku nr 4 rośnie, później pomimo zapychania pamięci maleje aż do kroku nr 9 (gdzie akurat było to oczekiwane), później jego zachowanie było już, że tak to nazwę, normalne. Szczególnie jest to widoczne między krokiem 7 a 8, później w wykresach poszczególnych aplikacji będzie widać dokładnie takie samo zachowanie. Zajętość pamięci można powiedzieć, jest odzwierciedleniem VM Size z „pewnym dodatkiem”, łatwo zauważyć, że jej zachowanie jest bliźniaczo podobne, trzeba tylko wziąć pewną poprawkę na wynik wielkość VM Size.

Jakie są, więc wnioski z tego? Czym w rzeczywistości są prezentowane w programie wartości? Memory Usage jest raczej pewnym, że jest to ilość danych ile „siedzi” w fizycznej pamięci operacyjnej. VM Size z definicji (o czym pisałem na początku tej części artykułu) jest ilością pamięci jaką sobie dany program alokuje, choć nie znaczy to, że to miejsce musi być zajęte. Jeśli więc przyjmiemy to za prawdę, to w takim razie, czym w rzeczywistości jest wartość podawana w pasku statusu Menadżera zadań? Gdyż widać dość wyraźnie, że wielkość tego ostatniego ma się nijak do Memory Usage.

Szukając rozwiązania tego problemu, próbowałem szukać innych definicji VM Size, czy wysuwać kolejne, inne tezy. Jednym z pomysłów (a i kilka osób mnie to zaproponowało) było stwierdzenie, że VM Size jest w rzeczywistości odbiciem pamięci RAM w pliku pagefile.sys wraz z danymi, które nie znajdują się w fizycznej pamięci, a które system zestronicował. Jednak pomysł ten dość szybko upadł, proszę popatrzeć na punkty od nr 1 do 4. Rozwinięciem tego było, stwierdzenie, że tak różnica może wynikać z wielkości jądra systemu, które nie jest stronicowane w całości. Tak się jednak składa, że jądro w systemie Windows 2000 zajmuje w całości od 30 do 40 MB a niestronicowane jest nie więcej niż 10 MB, a różnica w punkcie nr 2 wynosi aż 30 MB, nie jest to realne.

Zastanówmy się jeszcze czy zarządzanie pamięcią zarówno tą wirtualną jak i fizyczną jest właściwe. Generalnie trzeba przyznać, że system zachowuje się dość przewidywalnie i faktycznie wyrzuca z pamięci to, co nie jest aktualnie wykorzystywane, ale z pewnym opóźnieniem. I tak też powinno być. Dziwnym jednak zachowaniem jest wykorzystywanie jedynie 200 MB pojemności pamięci. Czemu nie skorzystał z jej pozostałej ilości?

Przejdźmy do wykresów poszczególnych aplikacji.

MS Word

Wykres MS Word:

Jak widać w początkowej fazie aplikacja zajmuje tyle samo Memory Usage co i VM Size, dopiero w fazie 6 jej zajętość w Memory Usage zaczyna drastycznie spadać, aż do kroku nr 8. W kroku nr 9 aplikacja została przywrócona z paska zadań i dlatego też użycie pamięci wzrosło. Widać tutaj bardzo dobrze zarządzanie pamięcią systemu operacyjnego, ile czasu zajęło mu „stwierdzenie”, że ta aplikacja nie jest przez nas używana.

explorer.exe

Wykres explorer.exe:

Powłoka systemowa zachowuje się dość niestandardowo. VM Size praktycznie cały czas na tym samym poziomie 3 MB, dopiero na końcu, kiedy odpalałem kilkadziesiąt apletów wtedy urosła. Natomiast Memory Usage pewne wahania ma, ale generalnie stały poziom utrzymuje.

Menadżer zadań

Wykres Menadżer zadań:

Podobnie zachowuje się Menadżer zadań (Task Manager), który ciągle utrzymuje stałą wielkość VM Size, a jedynie ze względu na ciągłą pracę notujemy wzrost Memory Usage. Tutaj obserwujemy też dowód na to, że VM Size nie można bezpośrednio wiązać z Memory Usage, jak widać VM Size jest mniejsza niż Memory Usage.

Internet Explorer

Wykres Internet Explorer:

Trochę odmiennie zachowuje się natomiast Internet Explorer. VM Size ma generalnie na tym samym poziomie, Memory Usage praktycznie cały czas spadało.

Macromedia Fireworks

Wykres Macromedia Fireworks:

Kolejnym obserwowanym przez nas programem jest Macromedia Fireworks, to w nim tworzyliśmy zrzuty ekranu. Program zachowuje się dość typowo, jeśli chodzi o kolumnę VM Size, jednak Memory Usage już jest mniej normalne. Program w kroku 7 zaczął już zmniejszać swoje zapotrzebowanie na pamięć fizyczną i takim sposobem dotarł do kroku nr 9. Faza 10’a wynika bezpośrednio z poczynionych w niej działaniach, nic niezwykłego.

Corel Draw 9

Wykres Corel Draw 9:

Corela Draw nie zaskakuje nas niczym, zachowuje się dokładnie tak samo jak Macromedia Fireworks.

WP Kontakt

Wykres WP Kontakt:

WP Kontakt zachowuje się również dość specyficznie. Już w 5 kroku system zaczął usuwać go z pamięci, by w kroku 8 zejść do 2 MB. VM Size na stałym poziomie 8 MB.

Czym więc są te wartości podawane w menadżerze zadań? Postaram się to wytłumaczyć jak najbardziej obrazowo i jednocześnie na przykładzie.

Najbardziej standardowym ustawieniem systemu jest wielkości pliku stronicowania 1,5 razy większa niż posiadana pamięć operacyjna. Przedstawia to rysunek nr 1:

Niebieski obszar to wielkość fizycznej pamięci RAM, pomarańczowy to jest plik stronicowania, natomiast szary obszar to jest tzw. plik oryginalny, czyli fizyczne miejsce na dysku, w którym został zapisany interesujący nas program. Dla lepszego zobrazowania cały szary obszar jest pewnym wycinkiem miejsca na dysku, zawiera również inne programy, lub system operacyjny. Dla przypomnienia odsyłam do punktu nr 3, a dokładnie do definicji stronicowania ukrytego. Proporcje zawarte na obrazku nie są w jakiś sposób wiążące, chodzi o generalne przedstawienie zachodzącego zjawiska, a nie przedstawienie proporcji. Po prostu tak będzie mi łatwiej to pokazać.

Etap 1

Zaczynamy nasze wirtualne testy. Włączamy jakiś program:

Rysunek nr 2

Przypomnijmy sobie jedną rzecz – istnieje stronicowanie jawne i niejawne. Teraz zaglądamy w menadżer zadań (Task Manager) i widzimy tam trzy interesujące nas elementy: pierwszy to kolumna Zajętość pamięci (Memory Usage), mówiąca nam ile to pamięci fizycznej zajmowane jest przez dany program, drugim interesującym nas elementem jest Rozmiar pamięci wirtualnej (VM Size), który mówi nam ile dany program zaalokował sobie prywatnej pamięci. Z kolei trzeci to jest liczba pokazywana w pasku statusu programu – Zajętość pamięci (Mem Usage), określająca… no właśnie co określająca, teoretycznie tyle ile wszystkie uruchomione przez nas aplikacje razem z systemem zajmują w pamięci.

Zielony obszar to jest obszar pamięci, jaką zajmuje dany program. Jak widać program nie został załadowany w całości, a jednak z niego korzystamy (stronicowanie niejawne – zrzut ekranu), po prostu system nie załadował tej części aplikacji, która nam nie jest w tym momencie potrzebna. Czarny obszar to jest pamięć wirtualna (VM Size), czyli to, co sobie dany program zaalokował dla siebie i żaden inny proces nie może go wykorzystać. Obszar ten jest dość interesujący z tego powodu, iż może być on pusty, bądź w 100% pełny. Program niezależnie od swoich potrzeb alokuje sobie pewną ilość pamięci, gdy jego potrzeby przekraczają aktualną pojemność tego obszaru aplikacja automatycznie sobie go zwiększa. Jednocześnie jego zajętość jest liczona do licznika w pasku statusu menadżera zadań. Obszar ten może być większy lub mniejszy niż sam program, wszystko zależy to od aplikacji, jednakże regułą jest, że jest jednak większy. Znajdować się on może w pamięci RAM jak i w pliku wymiany. Jest on wykorzystywany przez program do różnych celów, czasami do przechowywania danych tymczasowych, lub obliczeń, generalnie nie jesteśmy w stanie tego stwierdzić.

Etap 2

Jak się okazało ten nasz „jakiś” program to jest aplikacja do obróbki grafiki 🙂 Otwieramy w nim powiedzmy mapę bitową. Zmiany obrazuje rysunek nr 3

Zmiany można podsumować kilkoma słowami:

• zwiększyła się wielkość wykorzystywanej pamięci fizycznej.
• zwiększyła się zajętość pamięci przez program.
• program zaalokował większy obszar pamięci wirtualnej.

Tutaj bardzo dobrze widać, co wspomniane przeze mnie elementy tak naprawdę pokazują. Zajętość pamięci przez program wzrosła, aczkolwiek program nadal nie doczytał pozostawionych na dysku fragmentów samego siebie. VM Size oczywiście wzrosło, gdyż program „stwierdził”, że możliwe będzie zapotrzebowanie na większą ilość pamięci.

Oczywiście nie będziemy sprawdzać, co się będzie dziać w dalszych pompowniach naszego przykładowego programu, można to w dość łatwy sposób wydedukować.

Etap 4

A co się stanie, gdy w tym momencie uruchomimy np. grę i ta jakże pamięciożerna aplikacja zajmie cały obszar dostępnej fizycznej pamięci RAM? Wraz z rosnącym zapotrzebowaniem gry na pamięć nasz program będzie powoli „spychany” do pliku wymiany, aż gra zajmie cały dostępny dla niej obszar. Sytuację obrazuje ten oto obrazek:

Zauważyć można przeniesienie całości wirtualnej pamięci programu do pliku wymiany oraz to samo stało się z właściwym mu programem. Drugie spostrzeżenie oczywiście wymaga pewnego rozwinięcia, gdyż jak zapewne wszyscy z Was zauważyli zmieniły się proporcje udziałów tego programu w pamięci RAM a na dysku twardym. Po prostu teraz większa część, niż przedtem, programu znajduje się na dysku twardym. Jest to efekt stronicowania niejawnego, po co system by miał trzymać go w pamięci wirtualnej, jeśli go będzie potrzebował, to odczyta go z oryginalnego pliku, nie ma sensu tracić miejsca. Oczywiście proszę tutaj nie sądzić, że te dane na dysku twardym zostały przeniesione, ja tylko chciałem to zobrazować i tak jest to łatwiej pokazać – pewne uproszczenie.

Etap 5

A wyobraźmy sobie, co się stanie, gdy wyłączymy plik stronicowania i jedyne co będziemy mieć dostępne to będzie fizyczna pamięć RAM. Sytuację taką przedstawia rysunek 5:

Tłumaczyć rysunku myślę, że nie trzeba, zobrazowane jest to wystarczająco jasno. Jak widać taki stan jest zdecydowanie lepszy niż sytuacja w której mamy plik stronicowania, gdyż pozbywamy się stronicowania jawnego. Co się jednak dzieje w momencie, gdy zaczyna nam brakować pamięci? Jak się okazuje Windows zaczyna nieco inaczej zarządzać pamięcią. Już nie jest tak rozrzutny w dawaniu tak dużych wartości VM Size, zaczyna oszczędzać. Objawem tego jest wzmożone stronicowanie niejawne kosztem braku stronicowania jawnego, które akurat w tym momencie byłoby zdecydowane lepsze z punktu widzenia wydajnościowego.

Podsumowanie

Zacznijmy od początku 🙂

Memory usage czyli zajętość pamięci (to co obrazuje pierwsza kolumna – nr 1) jest ilością jaką pamięci jaką zajmuje dany program. Obszar ten jest doliczany do wielkości podawanej w pasku statusu programu (nr 3).

VM Size jest obszarem zaalokowanej pamięci przez dany program, nie mogącej jednocześnie być wykorzystywanej przez inne procesy. Obszar ten może być pusty bądź pełny, jednak jego zapełnienie bezpośrednio wpływa na wartość podawaną. Związek, jaki wynika z zamieszczonych obrazków między Mem Usage oraz VM Size jest dość jasny. Gdybyśmy z Memory Usage wyłączyli sam program w sensie samego kodu bez otwartego powiedzmy przykładowego pliku obrazka, to wszystko to znajduje się w VM Size. Innymi słowy każdy otarty dokument, każdy otwarty plik graficzny jest w rzeczywistości trzymany w pamięci wirtualnej (prywatnej), to tam są przechowywane wszelkie dane oprócz samego programu.
Licznik zajętości pamięci podawany w pasku statusu menadżera zadań to z kolei rzeczywista zajętość pamięci, jest to suma zajętości uruchomionych programów oraz tego co cały czas zajmuje sam system operacyjny.

8. Kilka słów od autora.

Czytając artykuł, szczególnie końcówkę, można odnieść wrażenie, że w jakiś sposób faworyzuję Windows’a 2000. Mówię stanowczo NIE! To co napisałem jest wynikiem trzyletniego używania tych systemów walki o jak najwydajniejsze działanie – zawsze miałem mało Ram-u, najpierw 64, teraz 256 MB.

Ktoś uważny, mający już pewne pojęcie o tym winien zauważyć, że algorytmy stworzone przez firmę Microsoft nie są jednak idealne. Bardzo ładnie widać to na przykładzie XP.

System pomimo zajętości pamięci w 50% i tak przenosi dość duże ilości danych do swapa… właśnie przenosi, czy nie mógłby ich skopiować tam? Wiem, że w tym momencie trzeba by nieco inaczej zaadresować „komórki” w swapie, ale myślę, że niebyły to wielki problem. Po prostu taki algorytm byłby wręcz idealnym rozwiązaniem. System w tle kopiuje praktycznie całą zawartość Ram-u do pagefile i w razie konieczności użycia większej ilości pamięci po prostu usuwa dawno nieużywane dane, czynność taka byłaby o wiele szybsza, niż przenoszenie w przypadku W2K, oraz mniej problematyczna z punktu widzenia nie załadowania pamięci w tak dużym stopniu w przypadku XP. Dochodzi do tak abstrakcyjnych sytuacji, że mając 2 GB RAM system i tak cache’uje dane pomimo tego, iż praktycznie nigdy nie mamy szans nawet dotrzeć do choć 70% zajętości pamięci (mówię tutaj o standardowej pracy na komputerze). System zachowuje się jakby nadal miał mało pamięci.
9. Podsumowanie

Wreszcie koniec 🙂 Mój artykuł jest takim omówieniem tematu, który powinien większości z Was dobrze naświetlić problem stronicowania w systemie Windows. Pominąłem tutaj celowo omawianie poszczególnych algorytmów stronicowania (FIFO i inne), pominąłem też opis dokładny adresowania i przenoszenia stron z pamięci i do pamięci operacyjnej, gdyż uważam, że kwestie te są dla nas mało istotne z punktu widzenia przyspieszenia pracy naszego komputera, a ktoś wnikliwy, łakomy na wiedzę, jeśli będzie chciał to z pewnością poszuka dogłębniejszych informacji, które zresztą mogę mu wskazać.

Grzebałem dość dużo w Internecie, niestety ciężko jest znaleźć coś rzeczowego, coś przystępnego, które by mówiło dość dokładnie o stronicowaniu, mam nadzieję, że ten poradnik będzie takim właśnie źródłem informacji.

Od was oczekuję konstruktywnej dyskusji, mile widziane opinie, a najbardziej te negatywne 🙂

Chciałem jeszcze na końcu podziękować kumotrowi Sneer82 za pomoc, dzięki, której mam jakiekolwiek pojęcie o Windows 2003. Podziękowania również ślę do Mirka (zainteresowani wiedzą kto) za to, że jako jeden z niewielu potrafił konstruktywnie dyskutować ze mną, poszerzając moją wiedzę. BIG THANKS dla Jaśqa, który tłumaczył, to czego nie kumałem z angielskiego. No dobra kończę już kończę 🙂