We współczesnych OS'ach wykonuje się jednocześnie wiele procesów i wątków. Wiele z nich używa pamięci masowej w tym samym momencie. Dodatkowo duża część aplikacji korzysta teraz z dysków w sposób asynchroniczny. Działa to tak, że po zgłoszeniu żądania zapisu/odczytu proces/wątek nie zatrzymuje się. Zajmuje się innym zadaniem, a do poprzedniego wraca jak dostanie od systemu informacje o wykonaniu żądania. Wszystko to powoduje, że konieczny jest mechanizm umożliwiający wysyłanie do pamięci masowej wielu operacji i/o jednocześnie. Nie oznacza to, że można zapomnieć o potwierdzeniach. Są one niezbędne dla poprawności składowanych danych.
Zależnie od systemu operacyjnego, mechanizm ten różnie się nazywa. Zasada działania jest jednak wszędzie prawie taka sama. Żądania zapisu/odczytu po wysłaniu do pamięci masowej są zapisywane w specjalnym buforze i zostają tam aż przyjdzie potwierdzenie ich wykonania. Dzięki temu system nie musi czekać z wysłaniem nowej operacji i/o na zakończenie poprzedniej. Wiele zleceń i/o może wykonywać się jednocześnie.
Opisywany mechanizm jest umiejscowiony zależnie od OS na poziomie dysku/lun'a albo portu FC/SCSI/iSCSI, albo w obu miejscach jednocześnie. Może też dotyczyć wszystkich dysków/portów lub każdego z osobna. Parametr systemowy odpowiedzialny za jego wielkość ma też różne nazwy. Przykłady:
AIX: indywidualnie dla każdego portu FC (num_cmd_elems) i dysku (queue_depth)
Solaris: globalnie dla wszystkich dysków (sdd_max_throttle)
Windows: indywidulanie dla każdego z portów FC (dla qlogic - execution throttle) globalnie dla wszystkich dysków (DriverParameter -> qd)
Wielkość tego buforu bezpośrednio wpływa na ilość IOPS jaką serwer jest w stanie zlecić do macierzy. Przykłady:
średni czas odpowiedzi=5ms, bufor=4, 1000/5 * 4 = 800 IOPS
średni czas odpowiedzi=5ms, bufor=8, 1000/5 * 8 = 1600 IOPS
średni czas odpowiedzi=5ms, bufor=8, 1000/5 * 8 = 1600 IOPS
Nie jest jednak powiedziane, że im większy bufor tym lepsza wydajność. Po drugiej stronie stoi bowiem macierz dyskowa, która też ma przecież swoje limity.
I teraz właśnie dochodzę do sedna sprawy. Czy czas odpowiedzi macierzy jest istotny dla jej wydajności? Nie ma wątpliwości, że tak. Dzięki buforom można jednak ograniczyć jego wpływ. Przykłady:
średni czas odpowiedzi=25ms, bufor=20, 1000/25 * 20 = 800 IOPS
średni czas odpowiedzi=25ms, bufor=40, 1000/25 * 40 = 1600 IOPS
średni czas odpowiedzi=25ms, bufor=40, 1000/25 * 40 = 1600 IOPS
Nie można przesadzić z wielkością buforów. Porty po stronie macierzy są w stanie obsłużyć ograniczoną liczbę niezakończonych operacji - od kilku do kilkunastu tysięcy.
Mechanizm ten nie spowoduje, że wydajność dysków wzrośnie do poziomu SSD, których czas odpowiedzi jest o rząd wielkości krótszy. Może jednak sprawić, że na dyskach 7200 RPM uda się zrobić konfigurację tak wydajną jak przy użyciu dysków 15000 RPM. Przykład dla RAID 0, 50% odczytów, 50% zapisów, 0 trafień w cache:
Cena tego rozwiązania będzie niższa, pojemność ponad 2x większa, a wydajność jak widać niemal identyczna.
2 komentarze:
Maro, dobrze, że to policzyłeś i jest dostępne w jednym miejscu. Kłopot tylko w tym, że większość aplikacji (poza bazami danych) jest względnie synchroniczna lub pracuje z małą ilością wątków więc i tak nie jest w stanie skorzystać z buforów po stronie OS, ponieważ czeka aktywnie na potwierdzenie (tak jakbyśmy w vdbench ustawili threads=1). Na taką wredotę pomaga niestety skorzystanie z maicerzy o BARDZO niskim czasie odpowiedzi np.: RAMSAN. Nie wiem jak zachowują się dyski SSD w klasycznych macierzach, może podobnie jak pamięci RAM.
Biorąc pod uwagę, że pewnie jakieś 95% aplikacji biznesowych to bazy danych zakładam, że większość i/o w e współczesnym Data Centre jest asynchroniczna. Tak przynajmniej wygląda to u mnie.
Prześlij komentarz