przystajnik

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 

Post navigation

Translate »