PageFile
Leon
Powiedzcie mi czy uzyskam poprawę wydajności jeśli na drugim (fizycznie)
dysku utworzę małą partycję FAT32, klaster powiedzmy 64KB przeznaczoną
wyłącznie dla PageFile?
Mam 2 dyski tej samej prędkości, 1-wszy NTFS (System), i drugi FAT32. Czy to
poprostu zbędne zawracanie sobie głowy :-) ?
Pozdrawiam
Leon
Leon
Pozdrawiam
Leon
Radoslaw Sokol
Leon wrote:
>
> Powiedzcie mi czy uzyskam poprawę wydajności jeśli na drugim (fizycznie)
> dysku utworzę małą partycję FAT32, klaster powiedzmy 64KB przeznaczoną
> wyłącznie dla PageFile?
Poprawa wydajności będzie, o ile ten drugi dysk jest rzadko
używany. W przeciwnym wypadku różnice nie będą wielkie.
Poza tym nie wiem, czy aż tak duży rozmiar klastra nie wpłynie
negatywnie na wydajność. Rozmiar strony w i386 wynosi 4 KB i
często tylko tak niewielkie porcje danych są odczytywane z
pliku wymiany -- klaster 4 KB lub 8 KB wydaje się być nieco
lepszym rozwiązaniem.
--
|""""""""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół | mailto:rso...@magsoft.com.pl |
| | http://www.grush.one.pl/ |
\................... ftp://ftp.grush.one.pl/ ............../
Mateusz
> Poprawa wydajności będzie, o ile ten drugi dysk jest rzadko
> używany. W przeciwnym wypadku różnice nie będą wielkie.
>
> Poza tym nie wiem, czy aż tak duży rozmiar klastra nie wpłynie
> negatywnie na wydajność. Rozmiar strony w i386 wynosi 4 KB i
> często tylko tak niewielkie porcje danych są odczytywane z
> pliku wymiany -- klaster 4 KB lub 8 KB wydaje się być nieco
> lepszym rozwiązaniem.
A czy nie bedzie mialo znaczenia fakt, że oba dyski sa podlaczone do tego
samego IDE, na drugim mam CDR i CDRW ?
Pozdrawiam
Leon
mosciak
>
> A czy nie bedzie mialo znaczenia fakt, że oba dyski sa podlaczone do tego
> samego IDE, na drugim mam CDR i CDRW ?
>
raczej nie.
duzo wieksze znaczenie ma obciazenie tego dysku i czy jest on szybki ( a nie
np. arcjaiczne pio4) ;)
nawet ata33 potrafi spowolnic system.
u mnie ata33 ze swapem sam na ide2 i bylo sporo wolniej niz swapowane na
dysku systemowym. dysk nie byl obciazony niczym innym poza swapowaniem.
wiec tzreba uwazac
mosciak
Radoslaw Sokol
Mateusz wrote:
>
> A czy nie bedzie mialo znaczenia fakt, że oba dyski sa podlaczone do tego
> samego IDE, na drugim mam CDR i CDRW ?
Na pewno na osobnych kanałach byłoby nieco szybciej, ale
różnica raczej nie będzie duża. Największy zysk wiąże się
z ograniczeniem ruchów głowic.
Godlike
namalowal/a w swojej wiadomosci <news:3EC0D59C...@magsoft.com.pl>:
> Hi,
>
> Mateusz wrote:
>>
>> A czy nie bedzie mialo znaczenia fakt, że oba dyski sa podlaczone do tego
>> samego IDE, na drugim mam CDR i CDRW ?
>
> Na pewno na osobnych kanałach byłoby nieco szybciej, ale
> różnica raczej nie będzie duża. Największy zysk wi±że się
> z ograniczeniem ruchów głowic.
Czyli podsumowujac. Lepszy swap na wolniejszym ale niuzywanym do innych
celow dysq, czy na wydzielonej dla swapa partycji (szybszego)dysq na ktorym
sa tez partycje z systemem i innymi rzeczami"?
--
Serwis Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Radoslaw Sokol
Godlike wrote:
>
> Czyli podsumowujac. Lepszy swap na wolniejszym ale niuzywanym do innych
> celow dysq, czy na wydzielonej dla swapa partycji (szybszego)dysq na ktorym
> sa tez partycje z systemem i innymi rzeczami"?
Nie. Lepszy na takim samym, ale oddzielnym dysku.
Założenie swapa na oddzielnym, ale wolniejszym dysku przyniesie
znikomy przyrost wydajności (jeśli w ogóle jakiś).
PS. To nie IRC. Nie używaj proszę wyrazów rodem z IRCa :)
Godlike
> PS. To nie IRC. Nie używaj proszę wyrazów rodem z IRCa :)
Ja i IRC, hahaha to Ci sie udalo.
Michal Kawecki
wiadomości news:3EBF620B...@magsoft.com.pl
> Hi,
>
> Leon wrote:
>>
>> Powiedzcie mi czy uzyskam poprawę wydajności jeśli na drugim
>> (fizycznie) dysku utworzę małą partycję FAT32, klaster powiedzmy
>> 64KB przeznaczoną wyłącznie dla PageFile?
>
> Poprawa wydajności będzie, o ile ten drugi dysk jest rzadko
> używany. W przeciwnym wypadku różnice nie będą wielkie.
>
> Poza tym nie wiem, czy aż tak duży rozmiar klastra nie wpłynie
> negatywnie na wydajność. Rozmiar strony w i386 wynosi 4 KB i
> często tylko tak niewielkie porcje danych są odczytywane z
> pliku wymiany -- klaster 4 KB lub 8 KB wydaje się być nieco
> lepszym rozwiązaniem.
>
plik, więc wielkość klastra nie ma tu żadnego znaczenia. "Klastrowanie"
dostępu do pliku wymiany odbywa się na poziomie systemu, który sam
określa, w którym miejscu swapa znajduje się poszukiwana informacja.
Zawartość pliku wymiany w żaden sposób nie jest odzwierciedlona w
tablicach FAT.
Moja propozycja, żeby używać maksymalnie dużych klastrów, miała na celu
raczej zmniejszenie wielkości tablic FAT, co pośrednio wpłynie na
zmniejszenie zajętości RAM.
M.
Radoslaw Sokol
Michal Kawecki wrote:
>
> Zaraz... przecież swap oznaczony jest w tablicy FAT jako pojedynczy
> plik, więc wielkość klastra nie ma tu żadnego znaczenia. "Klastrowanie"
> dostępu do pliku wymiany odbywa się na poziomie systemu, który sam
> określa, w którym miejscu swapa znajduje się poszukiwana informacja.
> Zawartość pliku wymiany w żaden sposób nie jest odzwierciedlona w
> tablicach FAT.
Tylko że obawiam się, że system nie ma za bardzo możliwości
odczytania z dysku fragmentu mniejszego niż rozmiar klastra,
co przy odczycie pojedynczych stron 4 KB i klastrze 64 KB
oznaczałoby konieczność odczytywania 16x więcej informacji,
niż naprawdę jest potrzebne. Nie jestem tego pewien jednak.
Michal Kawecki
> Hi,
>
> Michal Kawecki wrote:
>>
>> Zaraz... przecież swap oznaczony jest w tablicy FAT jako pojedynczy
>> plik, więc wielkość klastra nie ma tu żadnego znaczenia.
>> "Klastrowanie" dostępu do pliku wymiany odbywa się na poziomie
>> systemu, który sam określa, w którym miejscu swapa znajduje się
>> poszukiwana informacja. Zawartość pliku wymiany w żaden sposób nie
>> jest odzwierciedlona w tablicach FAT.
>
> Tylko że obawiam się, że system nie ma za bardzo możliwości
> odczytania z dysku fragmentu mniejszego niż rozmiar klastra,
> co przy odczycie pojedynczych stron 4 KB i klastrze 64 KB
> oznaczałoby konieczność odczytywania 16x więcej informacji,
> niż naprawdę jest potrzebne. Nie jestem tego pewien jednak.
>
że zarówno cache wbudowany w dysk twardy, jak i mechanizm cache zawarty
w samym systemie opracyjnym także operuje na klastrach większych niż
minimalne dopuszczalne 512 bajtów. W rzeczywistości zawsze wczytywane
jest więcej informacji (mechanizm read ahead), nie wiem tylko, o ile
więcej - i czy ewentualne opóźnienie, jakie spowoduje odczyt tej
nadmiarowej informacji (zaznaczam, że mowa o ciągłym obszarze dysku, bo
tak działa swap), ma jakikolwiek wpływ na wydajność pracy.
M.
Radoslaw Sokol
Michal Kawecki wrote:
>
> Tak właśnie jest, masz rację. Ale idąc dalej tym śladem - podejrzewam,
> że zarówno cache wbudowany w dysk twardy, jak i mechanizm cache zawarty
> w samym systemie opracyjnym także operuje na klastrach większych niż
> minimalne dopuszczalne 512 bajtów. W rzeczywistości zawsze wczytywane
> jest więcej informacji (mechanizm read ahead), nie wiem tylko, o ile
> więcej - i czy ewentualne opóźnienie, jakie spowoduje odczyt tej
> nadmiarowej informacji (zaznaczam, że mowa o ciągłym obszarze dysku, bo
> tak działa swap), ma jakikolwiek wpływ na wydajność pracy.
Tylko że swap raczej nie jest buforowany. Swap IMHO wykorzystuje
wyłącznie mechanizm page-in/page-out i za każdym razem powinien
odczytywać tylko tyle danych, ile trzeba. Odwołania do swapa
muszą jednak przejść przez sterownik systemu plików, który
może nakładać ograniczenia na ilość odczytywanych jednorazowo
danych choćby w ten sposób, że choć zwróci funkcji obsługi
wyjątku page-fault tylko odpowiednią stronę pamięci, to odczytać
będzie musiał cały klaster. Nie ma problemu, jeśli ten klaster
sobie wewnętrznie buforuje i zwraca dane z bufora przy odwołaniu
do sąsiednich stron -- problem będzie jednak już choćby przy
czytaniu stron rozrzuconych po pliku wymiany.
Wszystko to wynika z faktu, że swap nie ma swojej sekcji pamięci
obsługiwanej przez cache-managera, a więc read-ahead nie ma jak
zajść w ogóle.
Problem ten chyba był o wiele mniejszy w Windows 3.x ze stałym
plikiem wymiany, bo tam odwołania do swapa nie szły przez
system plików. Tam _prawdopodobnie_ możliwe było pominięcie
rozmiaru klastra i czytanie sektorami.
Jeszcze raz podkreślam, że to są moje przemyślenia oparte o
lekturę http://www.sysinternals.com/ i przeglądanie źródeł
ReactOS i nie muszą idealnie odpowiadać rzeczywistości ;)