Skocz do zawartości

mr.bungle

Użytkownicy
  • Zawartość

    4
  • Rejestracja

  • Ostatnio

Reputacja

0 Normalna

1 obserwujący

O mr.bungle

  • Ranga
    Nowy użytkownik
  1. VPS a wydajność dysku

    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.
  2. VPS a wydajność dysku

    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...
  3. 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.
×