VPS a wydajność dysku

[mr.bungle 0]

Witam

 

Nie mam dużego doświadczenia z wirtualizacją w środowiskach firm hostingowych i z tego co widzę (bardzo) wąskim gardłem jest dysk.

Moje pytanie brzmi - czy aby normalnie korzystać z baz danych, które robią commity (fsync) trzeba kupić dedyka, żeby nie bić się z resztą wirtualek o dostęp do dysku? Mam tu na myśli na razie ofertę w Polsce.

Mam malutki sklep działający na dysku SAS (kontener openvz), który generalnie mało commituje w ciągu dnia a mimo tego wiele z tych nielicznych commitów trwa dosyć długo (rekordzista ponad 20s!), przy średniej dla tych samych zapytań liczonej w ułamkach ms.

 

Czy wirtualizacja Xen zamiast OpenVZ zmienia cokolwiek w kwestii I/O? Czy faktycznie pozostaje dedyk (który w tej chwili kompletnie mi się nie opłaca biorąc pod uwagę co hostuję - przynajmniej nie w PL)?

 

Czy może wszyscy korzystający z VPSów jadą na mysql i MyISAM (jeżeli używają w ogóle bazy) i w związku z tym moje problemy są marginalne (w moim przypadku chodzi o postgresa)?

 

Będę wdzięczny za uwagi.

[theONE 526]

Tak z ciekawości, gdzie masz VPS i czy rozmawiałeś z dostawcą usługi o problemie z zapisem?

[mr.bungle 0]

Tak z ciekawości, gdzie masz VPS i czy rozmawiałeś z dostawcą usługi o problemie z zapisem?

 

Nie chcę na razie podawać nazwy firmy, pytałem bardziej ogólnie.

 

Problem został zgłoszony i przeniesiono mnie na inną maszynę gdzie jest lepiej (na razie mniej klientów), ale nie rozwiązało to do końca problemów, choć ze swojej strony odpaliłem więcej keszowania, wyłączyłem fsync dla mniej istotnych transakcji. Mimo tych zabiegów nadal kilka/naście transakcji dziennie nieźle się przycina.

Trudno mi sobie wyobrazić takiego VPSa przy dużym systemie transakcyjnym czy choćby średniej wielkości aplikacji, w której integralność danych jest istotna.

 

Stąd moje pytanie, czy to po prostu norma w takich środowiskach i jedynym sensowym rozwiązaniem jest dedyk?

 

Pracuję dla organizacji, która także używa openvz i mamy tam kilkadziesiąt baz postgresa w jednym kontenerze, w których jest bardzo dużo zapisów i takich problemów nigdy nie mieliśmy (fakt, że maszyna mocniejsza niż wspomniany VPS, aczkolwiek nie wiem jakie dyski), dlatego trochę mnie zaskoczyło to przycinanie przy 1 malutkim sklepiku...

[ritchey 91]

Nie chcę na razie podawać nazwy firmy, pytałem bardziej ogólnie.

 

Problem został zgłoszony i przeniesiono mnie na inną maszynę gdzie jest lepiej (na razie mniej klientów), ale nie rozwiązało to do końca problemów, choć ze swojej strony odpaliłem więcej keszowania, wyłączyłem fsync dla mniej istotnych transakcji. Mimo tych zabiegów nadal kilka/naście transakcji dziennie nieźle się przycina.

Trudno mi sobie wyobrazić takiego VPSa przy dużym systemie transakcyjnym czy choćby średniej wielkości aplikacji, w której integralność danych jest istotna.

 

Stąd moje pytanie, czy to po prostu norma w takich środowiskach i jedynym sensowym rozwiązaniem jest dedyk?

 

Pracuję dla organizacji, która także używa openvz i mamy tam kilkadziesiąt baz postgresa w jednym kontenerze, w których jest bardzo dużo zapisów i takich problemów nigdy nie mieliśmy (fakt, że maszyna mocniejsza niż wspomniany VPS, aczkolwiek nie wiem jakie dyski), dlatego trochę mnie zaskoczyło to przycinanie przy 1 malutkim sklepiku...

 

Podobnie jak kolega, też mam wykupionego VPS-a i to całkiem niezłego (CPU 3 GHz, 2 GB RAM), ale zauważyłem, że to dysk jest najsłabszym ogniwem. Mój system działa na PostgreSQL, dziennie zbiera kilka milionów rekordów (niecały 1 GB danych/dzień). CPU i RAM to nie problem, ale na niektóre COMMIT-y też muszę czekać ponad 1 minutę. Zrobiłem mały tunning ustawień postgres-a - trochę pomogło ale i tak te kilkanaście-kilkadzieścia sekund to standard. Fakt, że jedna transakcja zawiera do kilku tys. modyfikacji/wstawień - ale np. na moim zwykłym laptopie trwa to 5-10 (kilka razy szybciej).

Pytałem się administratora, mówił że na mojej maszynie inni mają hosting gier i to tak spowalnia - zwiększyli mi niby priorytet - ale nie pomogło to zbyt wiele. Czasem zauważam, że zwykłe polecenie "ls -la" potrafi trwać do kilku dobrych w katalogu z kilkoma plikami (i nie jest to wina opóźnień sieci - gdyż łączę się z innymi serwerami i tam jest ok).

 

Na produkcje to tylko dedyk z dyskami w RAID 0 lub SSD.

 

Pzdr

Mateusz

[mr.bungle 0]

Ech, pisalem i mi wcielo calego posta.

 

 

Mateusz - dokladnie te same objawy, ale u mnie bywa bardziej komicznie, bo 1 update w tabeli z kilkudziesiecioma rekordami i indeksem potrafil zajac np 10s. Dopoki to sa jakies operacje w tle to olac, ale jak mamy snchroniczny commit w aplikacji, to nie jest juz tak wesolo.

 

Poza tym tak jak pisales, czasem ls zamuli, czasem otwieranie pliku a czasem logowanie ssh trwa 30s i dluzej.

 

Ja akurat pytalem zawczasu czy na tych VPSach sa jakcys kolesie z serwerami gier i inni zajezdzajacy dyski i dostalem info, ze nie, wiec to pewnie cos innego (nie mam pojecia co).

 

RAM/CPU moze cieszyc na poczatku, ale potem zycie szybko weryfikuje. Mozemy sobie optymalizowac aplikacje na milion sposobow a glupi fsync nam ja zatrzyma na 10s i po ptakach.

 

Dedyk w Polsce jest poza moim zasiegiem. Na razie sobie poczekam, mamy jeszcze sprobowac z inna maszyna.

 

Ciekawi mnie wciaz co tak zatyka te dyski, ale tego raczej sie nie dowiem.

[crazyluki 114]

Pamiętajcie że VPS VPSowi nierówny. Decydując się na VPS w jakiejś firmie, patrzymy częstokroć tylko na parametry o których piszą nam sami sprzedawcy. Niestety Ci sami sprzedawcy nie informują o tym na jakich dokładnie dyskach (w jakiej konfiguracji, w jakiej ilości) oraz ilu klientów mieści się na referencyjnej maszynie. Zasadniczą regułą jest że hostingi masowe, stosują olbrzymi overselling zasobów gdyż aktualnie moc procesora liczona w GHz oraz pamięć ram są najtańszymi składnikami całej oferty.

Jakaś różnica musi w tym być skoro różnica cenowa między niektórymi firmami jest często kilkukrotna przy tych samych podstawowych parametrach.

jedni stosują raid 1 (gdy są budżetowi i w miarę dbają o bezpiczeństwo, inni raid 0 by upchać więcej klientów, lepsi dostawci stosuja raid 10 (który w odróżnieniu od poprzednich składa się z 4 dysków i łączy zalety obu tychże systemów).

Dochodzi także różnica - są firmy które korzystają ze zwykłych dysków SATA, z dysków SATA przeznaczonych do pracy ciągłeś, dysków SAS (prawdziwych a nie tylko SATA z inną obudową) oraz czasem SSD na swap dla klientów (na przykład ovh tak ma w swoich nowych cloudach - tyle że tam to jest liczone jako ram - chyba).

 

Generalizując - przed wyborem hostingu pod VPS warto by było spytać o możlwiość testu i sprawdzenie serwera samemu w odpowiadając nam sposób.

 

PS. przypominam ze hdparm tak średnio testuje wydajność dysków.

[ritchey 91]

Logowanie SSH 30 ... skad ja to znam, też się zdarza

 

Nie wiem czy mogę ujawnić jaka to firma, ale powiedzmy że to polska firma na literę "V", a lokalizacja serwera to Niemcy

 

Myślę, że przyczyną takiego stanu rzeczy jest to, iż dyski prawie zawsze są najsłabszym ogniwem systemu.

Przykładowo wydajność CPU czy przepustowość RAM-u jest obecnie mierzona w GB/s. Natomiast dysku to raptem kilkadziesiąt MB/s (przy dobrej fragmentacji) jak widac roznica jest mniej wiecej 100-krotna. Na dodatek procesory 4 rdzeniowe to dzisiaj standard, do tego dochodzi jeszcze HT, RAM też jest tani, natomiast aby zapewnić szybki dysk to już nie jest takie proste. SSD sa bardzo drogie i malo pojemne, SAS takze nie sa tanie, do tego jeszcze dochodzi RAID (kontrolery sprzetowe sa drogie) - zostaje jedynie software. Ale nawet jezeli mamy 2 szybkie dyski (kazdy np 75 MB/s). Łączymy je w RAID 0 to daje nam ok 150 MB/s. Tyle teorii. Teraz przy odczycie/zapisie bardzo wielu małych porcji lub plików można spokojnie założyć że transfer spada 5-10 krotnie (do tego są to fragmenty w różnych miejscach dysku) mamy może 10-15 MB . To jeszcze należy podzielić na 10-15 użytkowników którzy są na VPS-ie (mówię o budżetowym VPS) - i wychodzi nam może max. 1 MB/s . Ponadto wiadomo że wirtualizacja też daje swój narzut, do tego z dysku korzystają także inne procesy, system operacyjny, etc. Wynik jest jaki jest