Więc chcesz użyć SSD do przyspieszenia serwera? (03 maja 2010, 21:37:40)
Twój serwer, jak każdy szanujący się, spędzą większość czasu nudząc się oczekując na zakończenie operacji wejścia/wyjścia. Jak mu pomóc?
Na zakup serwera z terabajtem RAMu Cię nie stać. A szkoda, bo obsługiwałby obsceniczną liczbę setek tysięcy IOPS. Macierz SSD też pewnie przekracza limit na kredytówce. Milion operacji wejścia/wyjścia na sekundę — fun! Developerzy linuksa już usuwają wąskie gardła przy współpracy z F5100.
No to z ciężkim sercem decydujemy się tylko na ,,przyspieszenie''
podsystemu dyskowego używając SSD. Tylko co tam wtrynić… jeśli używasz programowego RAID,
możesz przejrzeć man mdadm i nauczyć się o write intent
bitmap. Który to wib dobrze będzie się czuł na SSD.
Ale to wciąż mało, mało i niewiele daje. OK, spójrzmy trochę wyżej na system plików. Jeśli posadowiłeś dane na ext3/4, XFS to super. Możesz wynieść journal na zewnętrzne urządzenie. Twoja baza danych wesoło zareaguje zwiększeniem ilości możliwych zapisów na sekundę z 200÷300 (HDD) do 10 tysięcy (sprawdzić, czy SSD Intela). Jeśli masz JFS to również możesz zeksternalizować dziennik. Ale mając JFS na produkcji powinieneś bać się $DEITY.
Oczywiście niebycie pingwiniarzem zaprocentowało. Używając
ZFS dostępnego w FreeBSD i Solarisie już dawno zastosowałeś dyrektywę log.
Obecnie Twój ZIL podkręca licznik zużycia komórek SSD, a Ty czytasz ten wpis
celem pośmiania się z przyjaciół drobiu arktycznego.
Załatwiliśmy zapisy, ale wciąż nie wszystko mieści się w buforze i odczyt czeka na odpowiednie położenie mechanicznej głowicy i talerza. Bo za złotówkę można dostać 2,3 GiB talerza w dysku. RAM jako bufor to tylko 0,008 GiB / PLN. SSD gdzieś pośrodku, ze jednego złocisza — jedna dziesiąta GB.
Odczytom pomóżmy jakąś pamięcią podręczną. ZFSowcy ponownie robią zieeeew, bo L2ARC od lat czyni im cuda z wydajnością. Podobnie podśmiewają się (wszyscy dwaj) użytkownicy DragonflyBSD. Tam swapcache załatwia brudną robotę.
Za to w linuksie dostępny jest pierdyliard rozwiązań, z których każde kuleje na inną nóżkę. I gotowe będzie za pół roku. Gimnastykować się można z FS-Cache i udawać, że wcale nie działa tylko z NFS, AFS i iso9660. Bo ma potencjał.
Potencjał ma też dm-cache. Działa na tylko sprawnie, że Facebook po drobnych przeróbkach i przemianowaniu na flashcache stosuje go produkcyjnie.
Można poczuć się jak saper i wypróbować bcache. Autor będzie wdzięczny za pomoc w ustabilizowaniu rozwiązania. Klienci za wysłanie ich danych w kosmos trochę mniej.
Obiecująco wyglądało dm-hstore. Heinz jednak zajął się innymi, bardziej pasjonującymi zabawkami i odłożył swoje dzieło na półkę. Wyraźniejszy jest cleancache, który teoretycznie może być zastosowany z SSD jako zapleczem.
Pozostaje mieć nadzieję, że Josef po zakończeniu walki z O_DIRECT zajmie
się trzymania drzewa intencji btrfs na zewnętrznym
urządzeniu. A potem dorobi drugi poziom cache w podobny sposób.
Może za pół roku.
Nie wiem czy dobrze zrozumiałem, ale chyba zrobiłeś mały błąd w zdaniu: "Bo za złotówkę można dostać 2,3 GiB talerza w dysku. RAM jako bufor to tylko 0,008 GiB / PLN. SSD gdzieś pośrodku, ze jednego złocisza — jedna dziesiątka GB". SSD ma droższy gigabajt niż gigabajt na talerzu. Nie wiem co to jest ZIL - sprawdzę w wolnej chwili. : ) Wpis jak każdy o ssd, ciekawy. : ) BTW u mnie był ostatnio wpis z dużą ilością komentarzy na ten temat.