przystajnik

Archiwum tagów la SSD

SSDcronTrim dla stroniących od systemd

Dyski SSD na dobre zadomowiły się już w naszych pecetach, ale nadal możemy spróbować poprawić ich wydajność, szczególnie gdy nasza dystrybucja nie korzysta z systemd oraz nie ma dedykowanego rozwiązania dla funkcji TRIM. Choć grono odbiorców skryptu SSDcronTrim będzie dość wąskie – większość współczesnych dystrybucji z marszu obsługuje poprawnie wspomnianą specyfikę dysków SSD – być może ktoś nadal opiera się przed systemd i nie wykonał samodzielnie skryptów dla CRONa.

Jak Cron Trimem zawiadował

Wszyscy użytkownicy dysków SSD są z pewnością zadowoleni ze skoku wydajnościowego jaki umożliwiły te urządzenia. Zadowolenie jest podwójne, bo teoretycznie nowa technologia, a działa bezproblemowo pod Linuksem. Jednak są niektóre niuanse tych dysków, o których warto pamiętać. Takim niuansem jest komenda Trim, porządkująca bloki pamięci flash zajęte przez usunięte pliki. Sposobów na użytkowanie tej komendy pod Linuksem jest kilka, od najpopularniejszej opcji ‚discard’ umieszczonej w opcjach /etc/fstab przy partycji dysku SSD, po polecenie fstrim, którego uskutecznieniem się zajmiemy. Po co? Niekiedy opcja ‚discard’ może prowadzić do niezamierzonych wahnięć w wydajności naszego systemu.

Lepiej późno niż wcale – TRIM w Ubuntu 14.04

UbuntuDyski SSD wyniosły na nowe płaszczyzny sprawność i responsywność systemów operacyjnych. Jednak ceną za wyjątkową wydajność odczytu i zapisu jest kilka specyficznych cech tych nośników. Jednym z takich niuansów jest kasowanie plików i to, w jaki sposób kontrolery tych dysków wykonują takie zadania. Wywód na ten temat mógłby być przydługi, nudnawy, oraz obfitowałbym w techniczną terminologię przyprawiającą niektórych o ból zębów. Koniec końców, warto wiedzieć, że na potrzebny sprawnego usuwania danych z dysków SSD, zostały one wyposażone w funkcję TRIM, która oszczędza cykle zapisu, ma zwiększyć prędkość tych operacji, oraz w końcu i po raz pierwszy zostanie domyślnie użyta w Ubuntu 14.04, jeżeli system wykryje, że posiadamy taki dysk.

Linux z dyskiem SSD za pan brat

Nikt nie lubi wlec się w ogonie postępu, dlatego co jakiś czas nachodzi człowieka nieprzemożona ochota na uaktualnienie konfiguracji swojego komputera. Nachodzi go jeszcze gwałtowniej, gdy taka zmiana niesie za sobą wymierne skutki w jakości pracy, oszczędności energii i poziomu decybeli jakie wydobywają się z naszego cyfrowego kompana. Tym razem wybór padł na dysk SSD – uzasadniony tym, że technologia ta osiągnęła już stan miarę dojrzały, pojemności takich dysków przekroczyły już dawno żartobliwe 32GB, w zamian otrzymujemy niebotyczne osiągi transferu, szybkość startu systemu i aplikacji, jak też pozbywamy się ‚zgrzytania’ dysku talerzowego. Minusem jest przypadłość takich dysków wynikają ze specyfiki nośnika – innymi słowy, im więcej i częściej na tym dysku zapisujemy, tym bardziej skracamy ich żywotność. Ale bez obaw, przypuszczalnie nikomu nie uda się ‚zajeździć’ takiego dysku do czasu wymiany na nowszy model. Ale czy da się coś zrobić, aby Linux był bardziej przyjazny dla dysków SSD?

Tyle RAMu w całym meblu…

Czasy są ciężkie, jak zawsze. Nie ma się co oszukiwać – oszczędzamy na czym się da. W tak żmudnych okolicznościach naszej codzienności, pofolgowanie sobie bezwstydnemu marnotrastwu pamięci RAM może się wydać nie na miejscu. Lecz niektórych muśnięcie dobrobytu obdarzyło maszynami o takiej ilości pamięci, że jej wykorzystaniu podołają tylko specjalistyczne, rozbudowane programy użytkowe. A jak tę nadwyżkę wykorzystać podczas zwyczajnego użytkowania naszego systemu? W końcu pamięć nie używana, to pamięć zmarnowana, a na dodatek to nie są już czasy dla maszyn z małą ilością pamięci…

Można liczyć na to, że nasze gigabajty połknie łakomy Firefox. Ale ten program nawet obwieszony kilkudziesięcioma kartami, zwykle nie wybiera się powyżej 1.5GB. Dla kogoś z pamięcią od 4GB wzwyż – to wciąż daleko od stanu ostrzegawczego. Można podczas przeglądania odpalić klienta poczty, czytnik RSS, odtwarzacz muzyki… I ciągle zmieścimy się w ~2GB. Można temat ciągnąć dalej i zapychać tę pamięć kolejnymi aplikacjami, lecz – jaki cel miałoby takie bicie rekordu? Może lepiej wykorzystać tę nadwyżkę na efektywne zwiększenie wydajności naszego systemu?

W temacie zagospodarowania pamięci istnieje wiele teorii i praktyk, ale tym razem naszą uwagę skupimy na niepozornym katalogu /tmp. Jak wieść gminna niesie, w tej lokalizacji przechowywane są pliki tymczasowe tworzone i używane przez system, środowisko, programy użytkowe, itp. Katalog ten po każdym restarcie systemu jest czyściutki jak łza i gotowy do ponownego zapełniania. Z natury jest to dość tłoczne i gwarne miejsce, gdyż jest tam zapisywanych, odczytywanych i kasowanych mnóstwo plików – i tak w kółko. Gdzie tu miejsce na optymalizację? Otóż katalog ten mieści się na dysku – a jak każdy wie, dyskowe operacje IO trwają dłużej niż te same operacje wykonywane bezpośrednio w pamięci. I oto rozwiązanie, które nasuwa się samo – przenieśmy katalog /tmp z dysku do RAMu!

Pomysł nie jest ani nowy, ani kontrowersyjny, ani pozbawiony pewnych wad. Jednak nadchodzące dystrybucje, np. Ubuntu 12.10 i Fedora 18, będą domyślnie wykorzystywały pamięć na potrzeby plików tymczasowych. Zminimalizowanie operacji zapisu na popularyzujących się nośnikach SSD, pozwala wydłużyć czas ich życia. Wykorzystanie tej metody w przypadku serwerów też się sprawdza (np. katalog tymczasowy dla MySQL). Dlaczego by nie spróbować i na naszym domowym biurku…

Teoria może i zgrabna, lecz co dalej? Otóż dalej okazuje się, że aby uzyskać kawałek pamięci RAM jako miejsce dla naszych machinacji, wystarczy… Zamontować ją we wskazanej lokalizacji. Do tego celu wymyślono właśnie systemy plików ramfs i tmpfs, czyli posługując się nomenklaturą sprzed wojny – ramdyski. Czy ramfs różni się czymś od tmpfs? W sposób zdecydowany:

    Ramfs:

  • Ramfs będzie sie rozrastał dynamicznie, zatem wymaga więcej uwagi z naszej strony. Jeżeli określimy, by ramfs używał np. 512MB naszej pamięci, to po zapełnieniu tego obszaru system nie zaprzestanie zapisywania danych zgłoszonych do zapisu w ramfs. Jak łatwo przewidzieć, mając 2GB na pokładzie i intensywnie użytkując zamontowany ramdysk, możemy doprowadzić do niestabilności, kiedy najzwyczajniej skończy się nam pojemność naszych kości RAM,
  • Ramfs nie używa obszaru wymiany swap,
    Tmpfs:

  • Tmpfs nie będzie się rozrastał bez naszej wiedzy i ponad przydzieloną mu pojemność pamięci. W przypadku przekroczenia ustalonych wartości, zostanie zgłoszony błąd ‚Brak miejsca na urządzeniu’,
  • Tmpfs wykorzystuje obszar wymiany swap,

Jak widać, tmpfs wydaje się być pewniejszym rozwiązaniem. Lecz czy tak samo wydajnym? Przeprowadzone testy za pomocą programu iozone wykazują niemal pomijalne różnice (QUIZ: znajdź element nie pasujący do reszty *):

  • HDD

(…)
Parent sees throughput for 10 mixed workload = 54.50 KB/sec
Parent sees throughput for 10 random readers = 1682.80 KB/sec
Parent sees throughput for 10 random writers = 231.86 KB/sec
(…)

  • Tmpfs

(…)
Parent sees throughput for 10 mixed workload = 2231.96 KB/sec
Parent sees throughput for 10 random readers = 4836.46 KB/sec
Parent sees throughput for 10 random writers = 2346.20 KB/sec
(…)

  • Ramfs

(…)
Parent sees throughput for 10 mixed workload = 1781,81 KB/sec
Parent sees throughput for 10 random readers = 3735.56 KB/sec
Parent sees throughput for 10 random writers = 2381.16 KB/sec
(…)

Czyli wiemu już co, wiemy już dlaczego, czas na rozstrzygnięcie dylematu – jak? Najrozsądniej, to najpierw to zamontować przeznaczony na ramdysk kawałek RAMu:

# dla tmpfs
sudo mount -t tmpfs -o size=512M tmpfs /tmp
# po testach - wpis na stałe w /etc/fstab
tmpfs /tmp tmpfs size=512M 0 0

… lub …
# dla ramfs
sudo mount -t ramfs -o size=512M ramfs /tmp
# po testach - wpis na stałe w /etc/fstab
ramfs /tmp ramfs size=512M 0 0

Parametr size=512M określa pojemność przeznaczonej na ramdysk pamięci – w tym przypadku 512MB. Należy pamiętać, że dla ramfs ten parametr jest mniej obligatoryjny, niż dla tmpfs.

Jak powyższe przekłada się na ogólną sprawność systemu? Na pewno nie możemy oczekiwać cudownego ‚zrywu’ – niektóre operacje przyśpieszą, inne nie, podobnie z aplikacjami. Wszystko zależy od ilości wykonywanych przez program/zadanie operacji na folderze /tmp. Niemniej, gra jest warta świeczki, a za jakiś czas i tak stanie się domyślnym rozwiązaniem w instalowanych przez nas dystrybucjach.

* Tak, osiągi HDD wyglądają jak nie z tej bajki

Translate »