Jak ulepszyć dysk SSD w systemie Ubuntu, aby uzyskać lepszą wydajność

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ę.

Benchmarki

Aby przetestować nasz dysk, użyliśmy pakietu testowego Phoronix. Jest bezpłatny 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:

• AMD Phenom II czterordzeniowy przy 3,2 GHz
• Płyta główna MSI 760GM E51
• 3,5 GB pamięci RAM
• AMD Radeon 3000 zintegrowany z 512 MB RAM
• Ubuntu Natty

No i oczywiście SSD, na którym testowaliśmy, to napęd Ony O86 64GB (117 $ na Amazon.com w momencie pisania).

Wybitne poprawki

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 operacyjnego na dysku. Jeśli chcesz 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łuższej perspektywie. 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 sprawić, że system będzie działał lepiej na dłuższą metę, dlatego stworzyliśmy naszą listę.

Tmpfs

Pamięć podręczna systemu jest przechowywana w / tmp. Możemy powieść 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 domyślne, 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ą dysku 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).

Wyniki testów porównawczych

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 poprawkach i ponownym uruchomieniu. 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 bez 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 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 16% wzrost wydajności.

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 poprawki ponownie zwiększają rozmiary 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ść wanilii ext4 jest zmniejszona o 75%, co jest poważnym powrotem do zmian, 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 uzasadnić, że nasze poprawki 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, wciąż 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 tworzeniu symulowanego jądra, około 40%.

Te testy porównawcze po prostu mierzą czas potrzebny na wyodrębnienie jądra Linux. Nie za duży wzrost wydajności tutaj.

streszczenie

Zmiany wprowadzone w gotowej konfiguracji Ubuntu ext4 odbiły się znacznym echem. 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 jedynym realnym miejscem, w którym widzieliśmy uderzenie wydajności, były proste wywołania systemowe, 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 było to szczególnie w przypadku 64-bitowego systemu Ubuntu Natty. 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 zmiany harmonogramu fstab i IO znacznie przyczyniły się do poprawy wydajności, więc warto spróbować na własnej platformie.

Czy masz własne testy porównawcze i chcesz udostępniać swoje wyniki? Masz jeszcze inne informacje, o których nie wiemy? Dźwięk w komentarzach!