Istnieje wiele wskazówek, jak ulepszyć SSD w Linuksie i wiele anegdotycznych raportów na temat tego, co działa, a co nie. Przeprowadziliśmy własne testy porównawcze za pomocą kilku konkretnych poprawek, aby pokazać rzeczywistą różnicę.
Aby zmierzyć nasz dysk, użyliśmy pakietu testowego Phoronix. Jest darmowy i ma repozytorium dla Ubuntu, więc nie musisz kompilować od zera, aby uruchomić szybkie testy. Testowaliśmy nasz system zaraz po nowej instalacji systemu Ubuntu Natty 64-bit przy użyciu domyślnych parametrów systemu plików ext4.
Nasze specyfikacje systemu były następujące:
No i oczywiście dysk SSD, na którym testowaliśmy, to napęd Ony O86 64 GB (117 $ na Amazon.com w momencie pisania).
Istnieje wiele zmian, które ludzie zalecają przy aktualizacji do SSD. Po odfiltrowaniu niektórych starszych plików, stworzyliśmy krótką listę poprawek, które dystrybucje Linuksa nie zawierają jako domyślne dla dysków SSD. Trzy z nich obejmują edycję pliku fstab, więc zrób to ponownie, zanim wykonasz następującą komendę:
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ć jego działanie, zapoznaj się z HTG Explains: Co to jest fstab Linux i jak to działa?
Unikać czasów dostępu
Możesz zwiększyć żywotność dysku SSD, zmniejszając ilość zapisu systemu na dysku. Jeśli potrzebujesz wiedzieć, kiedy ostatnio otwierano każdy plik lub katalog, możesz dodać te dwie opcje do pliku / etc / fstab:
noatime, nodiratime
Dodaj je wraz z innymi opcjami i upewnij się, że wszystkie są rozdzielone przecinkami i bez spacji.
Włączanie TRIM
Możesz włączyć TRIM, aby pomóc w zarządzaniu wydajnością dysku w długim okresie. Dodaj następującą opcję do pliku fstab:
odrzucać
Działa to dobrze w przypadku systemów plików ext4, nawet na standardowych dyskach twardych. Musisz mieć wersję jądra co najmniej 2.6.33 lub nowszą; jesteś objęty, jeśli używasz Maverick lub Natty, lub masz włączone backporty na Lucid. Chociaż nie poprawia to początkowo testu porównawczego, powinno to sprawić, że system będzie działał lepiej w dłuższej perspektywie, dlatego stworzyliśmy naszą listę.
Tmpfs
Pamięć podręczna systemu jest przechowywana w / tmp. Możemy powiedzieć fstab, aby zamontował to w RAM jako tymczasowy system plików, więc twój system mniej dotknie twardego dysku. 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 IO
Twój system nie zapisuje natychmiast wszystkich zmian na dysku, a wiele żądań przechodzi do kolejki. Domyślny harmonogram wejścia-wyjścia - cfq - obsługuje to w porządku, ale możemy zmienić to na takie, które działa lepiej dla naszego sprzętu.
Najpierw, wylistuj dostępne opcje za pomocą następującego polecenia, zastępując "X" literą napędu głównego:
cat / sys / block / sdX / queue / scheduler
Moja instalacja jest na sdzie. Powinieneś zobaczyć kilka różnych opcji.
Jeśli masz termin, powinieneś go użyć, ponieważ zapewnia on dodatkowe ulepszenia w dalszej części. Jeśli nie, powinieneś móc bezproblemowo używać noopu. Musimy powiedzieć systemowi operacyjnemu, aby używał tych opcji po każdym rozruchu, więc będziemy musieli edytować plik rc.local.
Użyjemy nano, ponieważ czujemy się komfortowo z linią poleceń, ale możesz użyć dowolnego edytora tekstu, który ci się podoba (gedit, vim, itp.).
sudo nano /etc/rc.local
Nad linią "exit 0" dodaj te dwie linie, jeśli używasz terminu:
echo deadline> / sys / block / sdX / queue / scheduler
echo 1> / sys / block / sdX / queue / iosched / fifo_batch
Jeśli używasz noop, dodaj tę linię:
echo noop> / sys / block / sdX / queue / scheduler
Ponownie zastąp "X" 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 zostały wprowadzone, musisz ponownie uruchomić. Potem powinieneś już wszystko ustawić. Jeśli coś pójdzie nie tak i nie możesz się uruchomić, możesz systematycznie cofać każdy z powyższych kroków, aż będziesz mógł ponownie uruchomić system. Możesz nawet użyć LiveCD lub LiveUSB, aby odzyskać, jeśli chcesz.
Zmiany w twoim pliku fstab będą trwały przez cały czas instalacji, nawet w przypadku aktualizacji, ale zmiana rc.local będzie musiała zostać przywrócona po każdej aktualizacji (między wersjami).
Aby wykonać testy porównawcze, uruchomiliśmy pakiet testów dysków. Najlepszym obrazem każdego testu jest zmiana konfiguracji ext4, a dolny obraz po wprowadzeniu poprawek i ponownym uruchomieniu komputera. Zobaczysz krótkie wyjaśnienie, co mierzy test, a także interpretację wyników.
Duże operacje na plikach
Ten test kompresuje plik 2GB z losowymi danymi i zapisuje je na dysku. Udoskonalenia SSD pokazują tutaj około 40% poprawę.
IOzone symuluje wydajność systemu plików, w tym przypadku zapisując plik 8 GB. Ponownie, prawie 50% wzrost.
Tutaj czytany jest plik 8GB. Wyniki są prawie takie same, jak w przypadku braku dostosowania ext4.
AIO-Stress asynchronicznie testuje wejście i wyjście, używając pliku testowego 2GB i rekordowego rozmiaru 64KB. Tutaj jest prawie 200% wzrost wydajności w porównaniu do wanilla ext4!
Małe operacje na plikach
Baza danych SQLite jest tworzona, a PTS dodaje 12 500 rekordów. Udoskonalenia SSD spowolniły w rzeczywistości wydajność o około 10%.
Apache Benchmark testuje losowe odczyty małych plików. Po optymalizacji naszego dysku SSD uzyskano około 25% wzrost wydajności.
PostMark symuluje 25 000 transakcji na plikach, w tym samym czasie 500, przy rozmiarach plików od 5 do 512 KB. To dość dobrze symuluje serwery internetowe i pocztowe, a po ulepszeniu zauważamy wzrost wydajności o 16%.
FS-Mark analizuje 1000 plików o łącznej wielkości 1 MB i mierzy, ile można całkowicie napisać i przeczytać w ustalonym czasie. Nasze ulepszenia znowu wzrosły dzięki mniejszym rozmiarom plików. Około 45% wzrostu z regulacjami ext4.
Dostęp do systemu plików
Testy systemu plików testowych Dbench wywołują klientów, podobnie jak robi to Samba. Tutaj wydajność vanilla ext4 jest zmniejszona o 75%, co stanowi poważny krok w zmianach, które wprowadziliśmy.
Widać, że wraz ze wzrostem liczby klientów zwiększa się rozbieżność wyników.
W przypadku 48 klientów różnica między nimi była nieco mniejsza, ale nasze usprawnienia uległy znacznej utracie.
Przy 128 klientach wydajność jest prawie taka sama. Możesz usprawiedliwić, że nasze usprawnienia mogą nie być idealne do użytku domowego w tego typu operacjach, ale zapewnią porównywalną wydajność, gdy liczba klientów znacznie się zwiększy.
Ten test zależy od biblioteki dostępu AIO jądra. mamy tutaj 20% poprawę.
Tutaj mamy wielowątkowy losowy odczyt 64 MB, a tutaj jest 200% wzrost wydajności! Łał!
Pisząc 64 MB danych za pomocą 32 wątków, 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 widać znaczącą korzyść dzięki początkowemu utworzeniu symulowanego jądra, około 40%.
Te testy porównawcze po prostu mierzą czas potrzebny na wyodrębnienie jądra systemu Linux. Nie za duży wzrost wydajności tutaj.
Zmiany wprowadzone w gotowej konfiguracji systemu ext4 w Ubuntu miały znaczny wpływ. Największy wzrost wydajności był w domenach wielowątkowych zapisów i odczytów, małych odczytów plików oraz dużych ciągłych plików odczytujących i zapisujących. W rzeczywistości jedyne prawdziwe miejsce, w którym widzieliśmy hit wydajności, to proste wywoływanie systemu plików, coś, na co użytkownicy Samby powinni uważać. Ogólnie rzecz biorąc, wydaje się, że jest to całkiem niezły wzrost wydajności, na przykład w zakresie hostowania stron internetowych i oglądania / przesyłania strumieniowego dużych filmów.
Należy pamiętać, że dotyczyło to przede wszystkim Ubuntu Natty 64-bit. Jeśli twój system lub dysk SSD jest inny, twój przebieg może się różnić. Ogólnie rzecz biorąc, wydaje się, że wprowadzone przez nas poprawki do harmonogramu fstab i IO znacznie przyczyniły się do lepszej wydajności, więc warto spróbować na własnym sprzęcie.
Czy masz własne benchmarki i chcesz dzielić się swoimi wynikami? Masz jeszcze inne informacje, o których nie wiemy? Dźwięk w komentarzach!
