sebak

@mcbarlo jeśli masz ratio kompresji 1.0x, to wyłącz kompresję, bo widać w Twoim przypadku jest ona zbędna ;-).

Zbyt duży cache, może mieć wpływ na wydajność, ale nie przy rozmiarze na poziomie 1 TB. Im więcej ramu tym lepiej, L2ARC dodatkowo obciąża Ci ram, gdyż trzyma tablicę danych w RAMie. Nie ma prostego przeliczenia RAM <-> pojemność, o ile nie używasz deduplikacji.

Kompresja prawie zawsze daje plus ;-). Zwłaszcza, że jeśli dane mają pomijalny stopień kompresji, nie są kompresowane na dysku. Jeśli odczyt do tych samych danych będzie zanim dane wypadną z kolejki ostatnio używanych, to warto stosować l2arc. Jeśli odczytujesz duży plik losowo, a następnie kolejny i kolejny, a dopiero później wracasz do pierwszego, to jest duża szansa, że cache dużo Ci nie da.

Powiedz mi @mcbarlo jaki to będzie odczyt, liniowy, random? Jaki zapis? Ogólnie cache ZFS'a działa bardzo prostu. Odczyt / Zapis danych trafia do ARC, który podzielony jest na dwa algorytmy: MRU i MFU. Jeden odpowiada za ostatnio używane dane, drugi za najczęściej używane dane. Wszystkie dane trafiają najpierw do cache przewidzianego dla ostatnio dodanych danych. Jeśli brakuje ramu, nowe dane, wypierają najstarsze dane. Jeśli do danych znajdujących w cache ostatnio dodanych odwołasz się chociaż raz, dane te zostaną przeniesione do drugiego algorytmy, z którego wypieranie danych działa analogicznie. Każde dodatkowe odwołanie do danych, przenosi istniejące tam dane na ostatnie miejsce do zwolnienia z cache. Załóżmy że masz 4GB ramu i masz zapis na poziomie 5GB, następnie odwołujesz się do 1 GB zapisanych danych. Nie znajdzie się on w cache. Stąd tak istotne jest dobór rozwiązań w zależności od charakterystyki danych. L2arc to przedłużenie ARC, dane które wypadają z ARC'a trafiają w idealnej sytuacji 1:1 do L2arc.

U mnie na hw, dyski dużo szybciej się zużywały niż w trybie jbod. Jeśli robisz małe obciążenie, to ma małe znaczenie czy stosujesz hw czy jbod, oraz jakich dysków używasz. Zfs on Linux trima nie wspiera, ale posiada różne zmienne konfiguracyjne których nie posiada freebsd. Freebsd z kolei posiada funkcje których nie posiada solaris i tak natywny ZFS posiada ich najmniej.

Wartości o których mówiłem poprzednio wyciągam właśnie z wartości smart, w zależności od dysków parametry 225, 241, 246. Przykład dla jednego z storage, w załączniku, oraz czysty smart dla dyski da0 z tego storage. Obecnie na żadnym serwerze nie posiadam już hw. Nigdy nie analizowałem tego, ze względu na fakt, że ZFS'a używam dla innej wirtualizacji niż ext4. Wszystkie OpenVZ mam na ext4, wszystkie KVM'y na ZFS'ie. KVM'y stoją też częściowo na innych dyskach niż OpenVZ(KVM wszedł do oferty 1,5 roku temu). Wcześniej pisałem, że wiele rzeczy może mieć wpływ na zużycie dysku. EXT4 na ZFS to nadal COW (copy on write), czyli zapis następuje na wolnej przestrzeni. Podczas gdy EXT4 modyfikuje dane na dysku. Pewnie to wpływa na różnice WL. Ewentualnie mam jeszcze jeden trop, ZFS na linuksie nie wspiera TRIM.

@Adam Szendzielorz to były stare czasy, około 3-4 lata temu. Wtedy działało to via hw RAID 10, ext4 (bez trim’a), kernel 2.6.32. Nie twierdze, że była to optymalna konfiguracja dla dysków SSD, ale przy analogicznych warunkach Crucial m550 nie stwarzał takich problemów. Wydajnościowe samsung wygrywał, jeśli chodzi o żywotność, Crucial. Ale jak pisałem wyżej, moje dyski SSD raczej dostają w kość jeśli chodzi o zapis.

Hej, jak podajecie endurance, to podajcie też powierzchnie na jaką się to rozkłada.

@Adam Szendzielorz pełna zgoda, dyski dobiera się pod planowane obciążenie i również uważam, że nie ma nic złego w stosowaniu optymalnego dysku do planowanego obciążenia. Ja niestety często generuje duże obciążenia na poziomie 50-250 TB zapisu na dysk 1 TB rocznie, ale to zasługa głównie charakterystyki usługi jaką jest serwer VPS.

A jakie były pierwsze modele dysków SSD jakie używaliście? Staram się sięgać pamięcią i przypomnieć sobie co to było ;-). Pamiętam, że pierwszym dyskiem SSD jaki użyłem z interfejsem SATA3 był Crucial C300 gdzieś w 2010 roku. To był oszałamiający wzrost wydajności jeśli chodzi o odczyt, dysk rozpędzał się już do 355 MB/s, zapis w zależności od modelu wahał między 55, a 215 MB/s ;-). Miałem kilka legendarnych dysków intela model X25-E, który charakteryzował się niesamowitą jak na tamte czasy wydajnością 250 MB/s odczyt i 170 MB/s zapis. Dysk był cholernie drogi i jako pierwszy miał sensowny endurance, dzięki zastosowaniu kości SLC. A wydajność 35k / 3k iops powalała. Mało kto pamięta, że pierwsze dyski SSD miały konstrukcję dużo bardziej zbliżoną do pendrive niż do współczesnych dysków SSD ;-). A jednak mimo wszystko dawały zauważalny wzrost wydajności, chociaż te konstrukcje były bardzo drogie i szybko padały. Nie pamiętam jakie dokładnie to były modele, ale było to zdecydowanie przed 2008 rokiem. Może Wy macie lepszą pamięć?

Pewnie się da, ale jednak to jest już ekstremalne odzyskiwanie danych. Na codzień preferuję RAID i KOPIE ;-)

Dyski Samsung 850, które mi padły zawsze zachowywały się podobnie. Były zupełnie nie widoczne przez serwer/komputer. Więc wydaje mi się że odzyskanie danych z nich mogły by być problematyczne ;-).

@Tomek test podesłany przez Ciebie jest bezwartościowy i nie ma tego jakkolwiek porównać do zastosowań produkcyjnych. Na żywotność dysku maja wpływ takie czynniki jak: - Obsługa lub nie TRIM - Zajętość dysku % (im dysk bardziej zajęty, tym dysk szybciej się zużywa) - Stopień zastępowania i migracji danych (zapis na SSD jest rozrzucany po najmniej zużytych komórkach. Wiec jeśli 50% danych jest stała i się nie zmienia, komórki w których one są trzymane były zapisywane 1x, natomiast cała reszta zapisu i zmieniajacych się danych nadpisuje cały czas 50% pozostałych komórek) - Typ danych (dyski SSD wewnętrznie kompresują dane) - Rozmiar rekordu - Temperatura pracy - i szereg innych czynników Ja powiem tylko tyle, że mam bardzo negatywne doświadczenie z samsungami 850 PRO. Są to jedyne dyski, które mi fizycznie padły. Co prawda po wyjęciu już z serwerów, ale jednak. Endurace który te dyski wytrzymywały, niewiele przekraczał ten na który była przewidziana gwarancja. Był to jedyny model który miałem i zdecydowałem się na całkowite zastąpienie go innymi rozwiązaniami.

@smarthost model to najważniejsza sprawa ;-). Był to dysk z serii desktop, czy enterprise? Kiedyś HW nie radziły sobie dobrze z obsługą dysków SSD i obsługą TRIM. Więc dyski via HW zużywały się zauważalnie szybciej. Nie wiem jak teraz jest z współczesnymi kontrolerami RAID, ponieważ od 4 lat używam tylko i wyłącznie trybu JBOD.

@nrm jeśli nie generujesz dużego zapisu, to dyski desktopowe bez problemu sobie radzą i ich awaryjność jest bliska zera. Tam gdzie generuje mały zapis stosuję dyski desktop, tam gdzie generuje duży zapis tam stosuje enterprise. Dysków SSD używam produkcyjnie od 6-7 lat i nigdy nie utraciłem ani bajta danych klientów ;-). @smarthost jakie modele?

Mój najbardziej wyeksplatowany dysk ma lekko ponad 36k godzin i cały czas działa bezawaryjnie. Jeśli chodzi zaś o endurance, najwięcej zrobiłem na jedym dysku ~560 TB i był to 1 TB Cruciam M550.

@nrm dobór dysków w moim przypadki zależny jest w dużem mierze od tego jaki zapis przewiduję. Dysk SSD to konstrukcja w miarę prosta i mało awaryjna, jeśli nie zużyjesz komórek pamięci. Z dysków PC, używałem głównie Crucial M550, Samsung 960 PCIe, Intel 750 PCIe. Z dysków Enterprise, używałem Micron M500DC i Samsung SM863. Miałem kilka Samsungów 850 Pro i w moich zastosowaniach te dyski szybciej się zużywały niż Cruciale M550. A podobno to Samsungi były dyskami bardziej PRO ;-). W każdej konfiguracji dyski SSD działają u mnie jako JBOD. Mam złe doświadczenie z kontrolerami SAS i dyskami SSD jako HW. Część dysków działa na macierzach ZFS, część bezpośrednio w serwerach. Na ogól nie zdarzyło mi się, by którykolwiek z tych dysków padł mi na maszynie produkcyjnej. Zawsze monitoruję SMART i jeśli coś mnie nie pokoi, to wymieniam dysk. Zdarzyło mi się 2 razy, że dysk wyjęty po niepokojących parametrach SMART już mi nie wstał, jak próbowałem go za jakiś czas przetestować.

@Adam Szendzielorz moje platformy mają stosunek odczyt/zapis na poziomie 20/80 %.

@Adam Szendzielorz niestety, ten najtańszy dysk może i będzie robił 20k, ale tylko przez chwilkę, po zapełnieniu cache wydajność Ci spadnie zdecydowanie. Na przykład taki Crucial MX300, którego używam do backupu przy długotrwałym obciążeniu jego wydajność spada Ci do około 5k iops: https://www.anandtech.com/show/10274/the-crucial-mx300-750gb-ssd-review-microns-3d-nand-arrives/2 Oczywiście to nadal dużo, ale trzeba mieć na uwadze, że większość dysków SSD przy długotrwałym obciążeniu ma wydajność zdecydowanie mniejszą niż przy krótkich testach na nieobciążonym systemie.

@SiXwishlist ale jednak ten temat dotyczy SSD, a nie innych czynników ;-). Co nie zmienia faktu, że w większości dla klienta usługa ma działać dobrze, a mało kto interesuje na czym ona stoi.

Masz tutaj np. PDF: http://www.samsung.com/semiconductor/global/file/insight/2017/04/best-practices-for-mysql-with-ssds-0.pdf jest o tyle ciekawy, że masz porównanie SAS, SSD AHCI i SSD NVMe. Kilka stron: https://blog.2ndquadrant.com/tables-and-indexes-vs-hdd-and-ssd/ https://blog.serverdensity.com/mongodb-performance-ssds-vs-spindle-sas-drives/ https://itblog.sandisk.com/the-impact-of-ssds-on-business-analytics-apache-hadoop-terasort-benchmark-using-sandisk-ssds/ https://serverfault.com/questions/507521/are-ssd-drives-as-reliable-as-mechanical-drives-2013/507536#507536 https://www.quora.com/Does-using-SSD-improve-the-performance-of-server http://www.profesorweb.es/wp-content/uploads/2012/11/ssd_vs_hdd_price_and_performance_study.pdf

@smarthost poszukaj w necie testów wydajności, jest ich trochę. Jak chcesz, możesz dawać takie przykłady klientom. Z moich obserwacji wynika, że tylko mały odsetek klientów zwraca uwagę na czym stoi usługa. Jednak gdy usługa źle działa, to większość użytkowników to widzi ;-).

Roztargnienie. Poprawiłem już ;-).

@Adam Szendzielorz przedstawił Ci ciekawe wyniki porównania: Strony www, przeważnie w testach i tak w większości lecą z ramu, więc trudno to odnieść jakkolwiek do dysków. Zaufaj doświadczeniu innych, my stosujemy dyski SSD od conajmniej 6 lat i różnice na plus były na tyle istotne, że dzisiaj poza kopiami nie stosujemy nigdzie dysków talerzowych.

Wszystko zależy od tego jaką masz infrastrukturę. W innym temacie pisałem, że tam gdzie się da używam ZFS'a. W przypadku ZFS'a backup jest prosty, mało zajmuje i można praktycznie z maszyny kopii odtworzyć maszyny wirtualne, a kompresja daje zazwyczaj ratio na poziomie 1.3-1,5x. Więc takie kopie, mają dużo mniejsze zapotrzebowanie na dane i wydajność niż inne metody. Serwery kopii zazwyczaj nie wymagają zbyt dużych zasobów. Ja miałem swego czasu kilka serwerków typu HP Microserver Gen 8 i działało to dobrze ;-). Uprzedzę przyszłe wydarzenia. Webh niedługo wycofa się z oferty OpenVZ, zostając tylko przy KVM. Głównym powodem takiej decyzji, były problemy z efektownym backupowaniem dużych ilości danych. Gdzie dla KVM i ZFS'a nie stanowiło to najmniejszego problemu ;-).