Woluminy: większa wydajność dysku pod 2K/XP Autor: Kane | Data: 02/07/03
| Wolumin rozłożony, czyli jak w prosty sposób zwiększyć wydajność pliku wymiany (i nie tylko) pod Windowsem 2000/XP. Cały pomysł na napisanie tego tekstu przyszedł mi do głowy w trakcie trwania sesji. Ci, którzy studiują bądź studiowali wiedzą jak jest - człowiek musi się uczyć, ale robi wszystko, żeby tylko tego nie robić. Tak więc czytając do egzaminu MSCE Training Kit: Windows 2000 Professional natknąłem się na rozdział dotyczący woluminów. Nie był on przewidziany programem zaliczenia, ale grzechem byłoby go nie przeczytać szczególnie, iż wspominał o wydajności. Tak przypomniał mi się dawno zapomniany temat dysków dynamicznych, który w czasach, kiedy Windows 2000 pojawił się w sprzedaży nie wzbudził we mnie jakiegoś szczególnego zainteresowania, chociażby dlatego, iż byłem posiadaczem zaledwie jednego dysku twardego. |
|
Na początek teoria
O cóż w tym wszystkich chodzi. Po konwersji naszego dysku do dysku dynamicznego pojawia się możliwość stworzenia na nim trzech rodzajów woluminów. Wolumin prosty składa się z przydzielonego mu miejsca w obrębie jednego dysku twardego. Wolumin łączony składa się z miejsca udostępnionego mu przez wiele dysków (maksymalnie 32) z tym, że sposób zapisu polega na tym, iż dane zapisywane są najpierw na dysku pierwszym aż do jego zapełnienia, następnie na kolejnych w ten sam sposób. W momencie uszkodzenia woluminu na którymkolwiek z dysków cały wolumin ulega zniszczeniu.
Najciekawszym woluminem, tym, dla którego powstał ten artykuł jest wolumin rozłożony. Łączy on logicznie miejsca na wielu dyskach twardych (maksymalnie 32) z tym, że w przeciwieństwie do woluminu łączonego dane zapisywane są jednocześnie równomiernie na wszystkich dyskach w jednostkach o wielkości 64 KB. System zapisu jest więc analogiczny do tego stosowanego w RAID 0. W tym wypadku jednak nie potrzebujemy kontrolera RAID, możemy wybrać sobie, ile miejsca chcemy przeznaczyć na nasz wolumin i gdzie on się ma znajdować w obrębie dysku. Niestety jednak jak i w RAID 0 w sytuacji, kiedy jeden z dysków odmówi posłuszeństwa tracimy całą zawartość woluminu (warto dodać, że Windows 2000 Server daje nam dodatkowo możliwość tworzenia woluminów mirrorowanych oraz RAID-5, czyli w przeciwieństwie do tych, które omawiam bardziej odpornych na uszkodzenia). Nie jest to więc najbezpieczniejsza metoda na przetrzymywanie ważnych dla nas danych, ale dlaczego nie mielibyśmy tego wykorzystać do innych celów.
Pierwsze co mi przyszło na myśl, to umieścić tam plik wymiany. Jest on bowiem integralną częścią każdego Windowsa i im większa jest jego wydajność, tym system pracuje sprawniej i szybciej. Ale na tym zastosowanie woluminu rozłożonego się nie kończy. Jego zalety na pewno dostrzegą osoby, które zajmują się obróbka video, a boją się budować macierze RAID 0 lub nie mają stosownego kontrolera. Mogą one bowiem wydzielić na swoich dyskach przestrzeń służącą jedynie do zrzucania i obróbki materiału video, a końcowy efekt magazynować już bezpiecznych rejonach dysków lub na płytach. Warunkiem tego jest posiadanie przynajmniej dwóch dysków twardych nieodbiegających od siebie wydajnością. Niestety osoby posiadające jeden dysk lub dwa dyski, z czego jeden bardzo wolny, nie będą miały szansy wykorzystać tej metody w praktyce.
Przejdźmy więc od teorii do czynu
Tak jak wspominałem wyżej, powinniśmy posiadać co najmniej dwa dyski twarde (trzy dawałyby konfigurację idealną) oraz system Windows 2000/XP. Pierwszą czynnością, którą musimy wykonać, aby założyć wolumin jest dokładne zaplanowanie tego co chcemy uzyskać. Jeśli zamierzamy używać tego woluminu do przechowywania pliku wymiany musimy zastanowić się, jaką powinien mieć wielkość (koniecznie z uwzględnieniem jakiegoś marginesu, żeby w razie zwiększenia potrzeb nie wykonywać całej pracy od nowa). Ja doszedłem do wniosku ze mając 512 MB ramu nie wykorzystam więcej niż 800 MB swapa. Jeśli mamy do dyspozycji dwa dyski twarde będziemy potrzebowali 400 MB wolnego niespartycjonowanego miejsca na każdym z dysków. Najlepiej do tego celu wykorzystać oczywiście obszar od 0-400 MB, gdzie transfer jest najwyższy.
Tak więc przed konwersją dysku na dysk dynamiczny dokonujemy zmniejszenia istniejących partycji o zadeklarowane przez nas 400 MB. Do tego musimy na samym końcu dysku zrobić przynajmniej 1 MB wolnego niespartycjonowanego miejsca, aby mógł zajść proces konwersji (jest to warunek konieczny). Wykonując tego rodzaju operację polecam wykonać kopię zapasową plików, gdyż niestety najpopularniejszy chyba obecnie program do zarządzania dyskami a mianowicie Partition Magic potrafi czasami zaskoczyć nas miłym komunikatem o błędzie i usunąć więcej niż byśmy tego chcieli. Sam proces konwersji do dysku dynamicznego nie usuwa przechowywanych danych (podobnie jak proces konwersji z FAT na NTFS), ale powrót do dysku podstawowego wiąże się już z zamazaniem informacji o woluminach i niestety także o przechowywanych na nich plikach. Jeśli mamy już przygotowany odpowiednio dysk możemy, rozpocząć proces konwersji do dysku dynamicznego. Wygląda on następująco:
Bez woluminów (kliknij, aby powiększyć)
Uaktualnij do dysku dynamicznego (kliknij, aby powiększyć)
Wybór dysków
Dysk do uaktualnienia
Zarządzanie dyskami
Uaktualnij dyski
Wolumin IBM DCAS (kliknij, aby powiększyć)
Po wykonaniu tej czynności zamiast partycji pojawiają się nam w Menadżerze urządzeń woluminy. Warto dodać, iż Partition Magic 8.0 rozpoznaje dyski dynamiczne, ale nie potrafi wykonywać na nich żadnych operacji, tak więc po konwersji jest już całkowicie nieprzydatny. Całość operacji będziemy teraz wykonywali stosując narzędzia dostępne w systemie.
Jeśli posiadamy już odpowiednio "spreparowane" dwa dyski możemy przystąpić do założenia na nich naszego woluminu. Może to wyglądać w ten sposób (zrzuty robione są z kilku procesów tworzenia woluminów, więc wygląd partycji i ilość dysków może się różnić - zdjęcia te mają pokazać krok po kroku jak wygląda proces zakładania dowolnych woluminów a nie tych konkretnych omawianych w artykule):
Utwórz wolumin (kliknij, aby powiększyć)
Kreator woluminów - pierwszy krok
Kreator woluminów prostych
Kreator woluminów łączonych
Kreator woluminów rozłożonych
Wybor dysku i wielkości
Wolumin na dysku IBM i Maxtor (kliknij, aby powiększyć)
Na powyższych zdjęciach SWAP to nasz wolumin a dysk z etykietą TRZECI to Maxtor. Czas zweryfikować naszą pracę - w testach.
Testy wydajności dysków
No i wreszcie jest. Czas więc na stosowne testy. Muszę przyznać, że miałem sporo wątpliwości co do słuszności tego rozwiązania. Wiadomo, że często coś, co w teorii wygląda na rozwiązanie idealne jest w brutalny sposób weryfikowane przez praktykę.
Wszystkie testy wykonywane były na następującym zestawie:
- System: Windows 2000 Professional + SP3
- Płyta główna: Epox 8RDA+ (nForce2)
- Procesor: Athlon XP 1700+ @1800 MHz (fsb 200MHz*9, 1.65V)
- Pamięci: 2x256 MB TwinMos (M-tec), PC2700 (333MHz), 6 ns
- Karta graficzna: Leadtek Winfast GeForce4Ti 4200 (250/600)
- Cdrom: Asus x50
I najważniejsza rzecz - dyski.
- WD Caviar 80 GB JB (7200 rpm, 8 MB cache) - systemowy, podzielony na dwie partycje NTFS 10 i 70 GB. Nie zakładałem na nim woluminu, służył jako dysk używany do określenia wydajności woluminu rozłożonego.
- IBM DTLA (7200 rpm) 30 GB - został przekonwertowany do dysku dynamicznego i na jego początku został utworzony wolumin rozłożony wielkości 400 MB. Na pozostałej części przechowywany był backup dysku trzeciego.
- MAXTOR 4D040H2 (5400 rpm) 40 GB - został przygotowany analogicznie jak IBM. Wolne miejsce pozostało puste. Za dysk podziękowania należą się Ion'owi z boarda, bez którego artykuł ten nie powstałby.
- IBM DCAS 2 GB SCSI - używany do testów także jako dysk dynamiczny z utworzonym na nim woluminem.
Założenie testu było następujące. Utworzony wolumin rozszerzony na Ibm'ach i Maxtorze postanowiłem testować przy pomocy dysku WD, który bez wątpliwości jest najwydajniejszy z całej czwórki. Na dyskach przed testem została przeprowadzona operacja defragmentacji. Ponieważ plik wymiany ma za zadanie wymieniać dane głównie z pamięcią operacyjną doszedłem do wniosku, iż testy jedynie w oparciu o dysk WD będą niepełne, dlatego też utworzyłem na potrzeby części pomiarów 200 MB ramdysk, który ostatecznie miał odpowiedzieć czy wydajność woluminu jest na tyle duża, iż warto się w ogóle tematem zainteresować. Program, który stosowałem (RamDisk2000Server) pozwalał na utworzenie dysku do 400 MB. Jednak po utworzeniu tak dużego ramdysku na potrzeby systemu pozostałoby tylko 112 MB wolnego ramu, co jest liczbą zdecydowanie za mała i zaburzyłoby wyniki oraz uniemożliwiło wyciągnięcie poprawnych wniosków. Tworząc 200 MB ramdysk pozostało ponad 312 MB do wykorzystania, co jest wg mnie wystarczającą ilością do prawidłowego funkcjonowania systemu.
Na pierwszy ogień poszedł wolumin rozłożony, zbudowany w oparciu o dwa IBM'y. Tutaj właściwie od razu wiadomo było, iż taka operacja skazana jest na niepowodzenie. IBM DCAS jest zdecydowanie za wolny, aby stworzyć jakiś sensowny duet z trzykrotnie szybszym IBM'em DTLA. Nie ma więc sensu tworzyć tego typu kombinacji, w których jeden dysk jest wyraźnie wolniejszy od drugiego.
IBM DCAS
Tak wygląda sytuacja po fizycznym odłączeniu IBM'a DCAS:
IBM DCAS z woluminem - odłączony (kliknij, aby powiększyć)
Niestety w takiej sytuacji system nie pozwala nam na manipulację pozostałymi woluminami. W pierwszej kolejności musimy odłączyć niedziałający wolumin i dopiero po wykonaniu tej czynności możemy wykonywać operacje na pozostałych.
O wiele ciekawiej zapowiadała się para MAXTOR + IBM DTLA. Najpierw jednak kilka krótkich testów tych dysków.
IBM DTLA
MAXTOR
WD JB
Testy dla Maxtora i Ibm'a Dtla przeprowadzone były na niespartycjonowanych (w przypadku HDTacha) i niezapełnionych (w przypadku SiSoft Sandry) dyskach. W przypadku WD ze względu na to, iż nie miałem gdzie zrobić backupu testy przeprowadzone zostały na zapełnionej w 70% pierwszej partycji.
Jak widać praktycznie obydwa dyski użyte do tworzenia woluminu oprócz czasu dostępu (gorszy wynik Maxtora jest oczywisty ze względu na to, iż pracuje on z prędkością 5400 rpm) mają bardzo podobne wyniki. Nie są to jakieś super wydajne konstrukcje, ale podobnie jak w macierzach RAID 0 chodzi o to, aby połączyć dwa tanie, niezbyt wydajne dyski i stworzyć z nich jeden duży, bardzo wydajny. WD odstawia je pod każdym względem, ale to raczej nic zaskakującego.
Nadszedł czas na testy naszego woluminu. Na początku postanowiłem sprawdzić wolumin Sandrą.
Muszę przyznać, że czegoś takiego się nie spodziewałem. Z niedowierzania zrobiłem kilka testów, ale za każdym razem wyniki były bardzo podobne. Ponad 44000 to wynik, który robi wrażenie. Wystarczy porównać to z wynikami poszczególnych dysków i wychodzi na to, że prawie podwoiliśmy wydajność każdego z nich. Jako że nie lubię specjalnie Sandry, gdyż uważam, iż jej testy nie zawsze oddają prawdziwy wzrost wydajności.. Postanowiłem uruchomić PcMarka2002. Wyniki, jakie otrzymałem tylko potwierdziły to, co wcześniej wyliczyła Sandra. Wynik nie jest już tak dobry, ale także zaskakująco wysoki (około 160% wydajności Maxtora).
Postanowiłem także dokonać pomiarów czasu, jaki zajmuje kopiowanie plików między założonym woluminem oraz dyskiem WD i utworzonym przeze mnie ramdyskiem.
Do testów użyłem plików o wielkości 730 MB oraz 200 MB i 5500 plików o łącznej wielkości 200 MB (ze względu na to, iż tyle właśnie miał utworzony przeze mnie ramdysk). W procesie kopiowania uczestniczyła pierwsza partycja dysku WD ze względu na to, że wydajność jej jest wyższa niż wydajność partycji drugiej (zrobiłem jeden test kontrolny, aby to potwierdzić - druga partycja nazywa się WD2). Wolumin roboczo nazywany jest na wykresach SWAP'em.
Jak widać wyniki są bardzo dobre. Kopiowanie z użyciem naszego woluminu i dysku WD jest dużo szybsze niż kopiowanie z użyciem pojedynczych dysków. Otrzymane wyniki podobne są do tych otrzymanych za pomocą Sandry i PcMarka2002.
Znacznie więcej czasu zajmuje kopiowanie z dysku użytego do tworzenia woluminu bezpośrednio na wolumin. Tutaj kilka słów wyjaśnienia.
Związane jest to z tym, iż jeden z dysków musi wykonywać jednocześnie operacje odczytu i zapisu. Ale czasy te są i tak dużo krótsze niż czas operacji kopiowania w obrębie każdego z dysków (szczególnie słabo wypadł stary IBM DTLA, którego wewnętrzna prędkość kopiowania pozostawia wiele do życzenia). Niestety tej niedogodności nie da się uniknąć posiadając jedynie dwa dyski (mając trzy, system może znajdować na osobnym dysku niż wolumin ze swapem). Biorąc jednak pod uwagę, iż działanie pliku wymiany polega na współpracy z pamięcią ram (pobieraniu danych i przesyłaniu ich z powrotem) sytuacja taka jak w teście pojawi się tylko wtedy, kiedy intensywnie będziemy używać jednego z dysków i jednocześnie równie intensywnie system będzie wykorzystywał plik wymiany.
Nie trzeba się obawiać spadku wydajności, pomimo iż wyniki tych testów są słabsze niż w przypadku kopiowania z woluminu na WD. Taka sytuacja jest przecież na porządku dziennym u większości użytkowników. Trzymają oni bowiem plik wymiany na tym samym dysku, co system i zainstalowane aplikacje. Lepiej jest jedynie wtedy, kiedy plik wymiany trzymamy na osobnym dysku, na którym nie ma poza nim nic, co system bądź użytkownik mógłby uruchomić (ja takiego rozwiązania nigdy nie widziałem i pewnie nie zobaczę, bo kto normalny dla tych paru procent wydajności cały dysk przeznacza tylko na swapa).
Najbardziej interesowało mnie jednak to jak zmienia się szybkość wymiany danych pomiędzy pamięcią operacyjną a plikiem wymiany. W tym celu zrobiłem pomiary z użyciem stworzonego przeze mnie ramdysku. Wyniki jakie otrzymałem, praktycznie nie wymagają komentarza (ze względu na to, iż pomiary trwały krótko, zrobiłem kilkanaście testów i wyciągnąłem średnią).
Szybkość kopiowania z i do woluminu jest większa nawet niż w przypadku szybkiego dysku WD. Wyjątkowo duże różnice obserwujemy w przypadku kopiowania bardzo dużej ilości małych plików. Wyniki kopiowania z ramu na Maxtora są ponad czterokrotnie gorsze niż z ramu do woluminu. To już robi wrażenie. Zresztą tak samo dobre są wyniki kopiowania z WD do Woluminu w porównaniu z kopiowaniem tej samej ilości plików na Maxtora.
Podsumowanie
Testy mówią same za siebie. Metoda ta idealnie nadaje się do zwiększenia wydajności pliku wymiany. Praktycznie rzecz biorąc, za darmo otrzymujemy przynajmniej 150% wzrost wydajności, który niewątpliwie przełoży się na szybkość działania systemu w czasie intensywnego korzystania z pamięci wirtualnej. Można też w ten sposób, choć trochę zrekompensować sobie mniejszą ilość pamięci Ram. Jest to także idealne rozwiązanie dla osób zajmujących się obróbką video, u których występuje efekt gubienia klatek w czasie przegrywania materiału z kamery. Niestety ze względu na małą ilość czasu, jaki miałem na wykonanie tych wszystkich testów nie udało mi się stwierdzić czy takie rozwiązanie ma realny wpływ na działanie gier (pominąłem także kilka testów z użyciem dysków gdyż wg mnie nic by nie wniosły). Sądzę jednak, że fani 3dmarka raczej nie powinni liczyć na jakiś oszałamiający przyrost punktów, ale bez wątpienia bardziej wymagające gry (szczególnie te bardzo RAMo-żerne) będą chodzić płynnej.
Chciałbym także podkreślić na koniec, iż tworzenie woluminów, jak każda operacja na dyskach twardych, obarczone jest ryzykiem utraty danych, więc wszystko co robicie, robicie na własną odpowiedzialność. Myślę że warto jednak zastanowić się nad tym rozwiązaniem.
|