Istnieje wiele wskazówek dotyczących ulepszania dysku SSD w systemie Linux i wiele niepotwierdzonych raportów o tym, co działa, a co nie. Przeprowadziliśmy własne testy porównawcze z kilkoma konkretnymi poprawkami, aby pokazać prawdziwą różnicę.
Benchmarki
Aby przetestować nasz dysk, użyliśmy Phoronix Test Suite . Jest bezpłatny i zawiera repozytorium Ubuntu, więc nie musisz kompilować od zera, aby przeprowadzić szybkie testy. Przetestowaliśmy nasz system zaraz po świeżej instalacji 64-bitowego Ubuntu Natty, używając domyślnych parametrów systemu plików ext4.
Nasze specyfikacje systemowe były następujące:
- Czterordzeniowy procesor AMD Phenom II o taktowaniu 3,2 GHz
- Płyta główna MSI 760GM E51
- 3,5 GB pamięci RAM
- Zintegrowana karta AMD Radeon 3000 z 512 MB pamięci RAM
- Ubuntu Natty
Oczywiście dysk SSD, na którym testowaliśmy, był dyskiem OCZ Onyx o pojemności 64 GB ( 117 USD na Amazon.com w momencie pisania).
Wyraźne poprawki
Istnieje wiele zmian, które ludzie zalecają podczas aktualizacji do dysku SSD. Po odfiltrowaniu niektórych starszych rzeczy stworzyliśmy krótką listę poprawek, których dystrybucje Linuksa nie uwzględniły jako domyślne dla dysków SSD. Trzy z nich obejmują edycję pliku fstab, więc wykonaj kopię zapasową, zanim przejdziesz do następującego polecenia:
sudo cp / etc / fstab /etc/fstab.bak
Jeśli coś pójdzie nie tak, zawsze możesz usunąć nowy plik fstab i zastąpić go kopią kopii zapasowej. Jeśli nie wiesz, co to jest lub chcesz odświeżyć, jak to działa, przyjrzyj się HTG wyjaśnia: Co to jest fstab systemu Linux i jak to działa?
Unikanie czasu dostępu
Możesz pomóc wydłużyć żywotność dysku SSD, zmniejszając ilość zapisu systemu operacyjnego na dysku. Jeśli chcesz wiedzieć, kiedy ostatnio uzyskano dostęp do każdego pliku lub katalogu, możesz dodać te dwie opcje do swojego pliku / etc / fstab:
noatime, nodiratime
Dodaj je wraz z innymi opcjami i upewnij się, że są oddzielone przecinkami i bez spacji.
Włączanie TRIM
Możesz włączyć TRIM, aby pomóc zarządzać wydajnością dysku w dłuższej perspektywie. Dodaj następującą opcję do pliku fstab:
odrzucać
Działa to dobrze w systemach plików ext4, nawet na standardowych dyskach twardych. Musisz mieć wersję jądra co najmniej 2.6.33 lub nowszą; jesteś objęty ochroną, jeśli używasz Maverick lub Natty, lub masz włączone backporty w Lucid. Chociaż nie poprawia to w szczególności wstępnych testów porównawczych, powinno sprawić, że system będzie działał lepiej w dłuższej perspektywie, więc znalazło się na naszej liście.
Tmpfs
Pamięć podręczna systemu jest przechowywana w / tmp. Możemy powiedzieć fstab, aby zamontował to w pamięci RAM jako tymczasowy system plików, aby twój system mniej dotykał dysku twardego. Dodaj następujący wiersz na końcu pliku / etc / fstab w nowym wierszu:
tmpfs / tmp tmpfs defaults, noatime, mode = 1777 0 0
Zapisz plik fstab, aby zatwierdzić te zmiany.
Przełączanie harmonogramów we / wy
Twój system nie zapisuje od razu wszystkich zmian na dysku, a wiele żądań jest umieszczanych w kolejce. Domyślny harmonogram wejścia-wyjścia - cfq - radzi sobie z tym w porządku, ale możemy to zmienić na taki, który działa lepiej dla naszego sprzętu.
Najpierw wymień dostępne opcje za pomocą następującego polecenia, zastępując „X” literą dysku głównego:
cat / sys / block / sdX / queue / schedule
Moja instalacja jest na sda. Powinieneś zobaczyć kilka różnych opcji.
Jeśli masz termin, powinieneś z niego skorzystać, ponieważ daje to dodatkowe poprawki w dalszej części. Jeśli nie, powinieneś móc używać noop bez problemów. Musimy powiedzieć systemowi operacyjnemu, aby używał tych opcji po każdym uruchomieniu, więc będziemy musieli edytować plik rc.local.
Będziemy używać nano, ponieważ dobrze znamy wiersz poleceń, ale możesz użyć dowolnego innego edytora tekstu (gedit, vim itp.).
Sudden / Etc / rc.ぉ lub l
Nad wierszem „exit 0” dodaj te dwa wiersze, jeśli korzystasz z terminu:
echo deadline> / sys / block / sdX / queue / scheduleer
echo 1> / sys / block / sdX / queue / iosched / fifo_batch
Jeśli używasz noop, dodaj tę linię:
echo noop> / sys / block / sdX / queue / scheduleer
Ponownie zamień „X” na odpowiednią literę dysku dla twojej instalacji. Przejrzyj wszystko, aby upewnić się, że wygląda dobrze.
Następnie naciśnij CTRL + O, aby zapisać, a następnie CTRL + X, aby zakończyć.
Uruchom ponownie
Aby wszystkie te zmiany zaczęły obowiązywać, musisz ponownie uruchomić. Potem wszystko powinno być gotowe. Jeśli coś pójdzie nie tak i nie możesz uruchomić systemu, możesz systematycznie cofać każdy z powyższych kroków, aż do ponownego uruchomienia. Możesz nawet użyć LiveCD lub LiveUSB do odzyskania Jeśli chcesz.
Zmiany w pliku fstab będą trwać przez cały okres instalacji, nawet po uaktualnieniu, ale zmiana lokalna rc będzie musiała zostać ponownie wprowadzona po każdym uaktualnieniu (między wersjami).
Wyniki testów porównawczych
Aby przeprowadzić testy porównawcze, uruchomiliśmy zestaw testów dysków. Górny obraz każdego testu znajduje się przed modyfikacją konfiguracji ext4, a dolny obraz po poprawkach i ponownym uruchomieniu. Zobaczysz krótkie wyjaśnienie, co mierzy test, a także interpretację wyników.
Operacje na dużych plikach
Ten test kompresuje plik 2 GB z losowymi danymi i zapisuje go na dysku. Zmiany w SSD pokazują tutaj około 40% poprawę.
IOzone symuluje wydajność systemu plików, w tym przypadku zapisując plik 8 GB. Znowu prawie 50% wzrost.
Tutaj odczytywany jest plik 8 GB. Wyniki są prawie takie same, jak bez dostosowywania ext4.
AIO-Stress asynchronicznie testuje dane wejściowe i wyjściowe, używając pliku testowego 2 GB i rozmiaru rekordu 64 KB. Tutaj jest prawie 200% wzrost wydajności w porównaniu do wanilii ext4!
Operacje na małych plikach
Tworzona jest baza danych SQLite i PTS dodaje do niej 12500 rekordów. Poprawki SSD tutaj faktycznie spowolniły wydajność o około 10%.
Apache Benchmark testuje losowe odczyty małych plików. Po optymalizacji naszego dysku SSD nastąpił wzrost wydajności o około 25%.
PostMark symuluje 25 000 transakcji na plikach, 500 jednocześnie w dowolnym momencie, z rozmiarami plików od 5 do 512 KB. To całkiem dobrze symuluje serwery internetowe i pocztowe, a po poprawkach widzimy 16% wzrost wydajności.
FS-Mark sprawdza 1000 plików o łącznym rozmiarze 1 MB i mierzy, ile z nich można w całości zapisać i odczytać w ustalonym z góry czasie. Nasze poprawki znowu się zwiększają, wraz z mniejszymi rozmiarami plików. Około 45% wzrost z korektami ext4.
Dostęp do systemu plików
Testy porównawcze Dbench testują wywołania systemu plików przez klientów, podobnie jak Samba. W tym przypadku wydajność wanilii ext4 spadła o 75%, co jest poważnym cofnięciem wprowadzonych przez nas zmian.
Widać, że wraz ze wzrostem liczby klientów rośnie rozbieżność w wydajności.
Przy 48 klientach luka między nimi się nieco zmniejszyła, ale nasze poprawki nadal powodują wyraźną utratę wydajności.
Przy 128 klientach wydajność jest prawie taka sama. Możesz rozumować, że nasze poprawki mogą nie być idealne do użytku domowego w tego rodzaju operacjach, ale zapewnią porównywalną wydajność, gdy liczba klientów zostanie znacznie zwiększona.
Ten test zależy od biblioteki dostępu AIO jądra. tutaj mamy 20% poprawę.
Tutaj mamy wielowątkowy losowy odczyt 64 MB, a tutaj jest 200% wzrost wydajności! Łał!
Podczas zapisywania 64 MB danych w 32 wątkach nadal mamy 75% wzrost wydajności.
Compile Bench symuluje wpływ wieku na system plików, reprezentowany przez manipulowanie drzewami jądra (tworzenie, kompilowanie, łatanie itp.). Tutaj możesz zobaczyć znaczną korzyść z początkowego utworzenia symulowanego jądra, około 40%.
Te testy porównawcze po prostu mierzą, ile czasu zajmuje wyodrębnienie jądra Linuksa. Nie za duży wzrost wydajności tutaj.
streszczenie
Zmiany, które wprowadziliśmy w gotowej konfiguracji ext4 Ubuntu, miały spory wpływ. Największy wzrost wydajności odnotowano w dziedzinie wielowątkowych zapisów i odczytów, odczytów małych plików oraz dużych ciągłych odczytów i zapisów plików. W rzeczywistości jedynym rzeczywistym miejscem, w którym widzieliśmy wzrost wydajności, były proste wywołania systemu plików, na co użytkownicy Samby powinni uważać. Ogólnie rzecz biorąc, wydaje się, że jest to całkiem solidny wzrost wydajności w przypadku takich rzeczy, jak hosting stron internetowych i oglądanie / przesyłanie strumieniowe dużych filmów.
Należy pamiętać, że dotyczyło to szczególnie 64-bitowego Ubuntu Natty. Jeśli Twój system lub dysk SSD jest inny, przebieg może się różnić. Ogólnie rzecz biorąc, wydaje się, że poprawki fstab i harmonogramu IO, które wprowadziliśmy, znacznie przyczyniły się do lepszej wydajności, więc prawdopodobnie warto spróbować na własnym sprzęcie.
Masz własne testy porównawcze i chcesz podzielić się swoimi wynikami? Czy masz jeszcze jedną poprawkę, o której nie wiemy? Brzmi w komentarzach!
