Serwer niedociążony, a chodzi jak krew z nosa

[zanik 0]

Wymieniliśmy serwer IBM x3500M2: 2x E5530; 8GB RAM; 2 x 146GB HDD; RAID Controller; 2x PSU tower na rack'owy, praktycznie tej samej konfiguracji, tylko z szybszymi procesorami i z większa liczba dysków. Oba miały Fedorę 12, Apacha i mysql do obsługi ca 200 - 300 użytkowników sieciowych z dużym wykorzystaniem bazy danych. Instalacje praktycznie identyczne na obu serwerach, a ten nowy z niewiadomych przyczyn dostaje zadyszki, choć poprzedni śmigał bez problemów. Teraz czasy reakcji z poniżej ułamka sekundy zamieniły się już przy średnim obciązeniu liczbą użytkowników, na 4, 8, 16 sekund, a klienci jęczą, że wszystko stoi. W tym czasie obciążenie procesora znikome, liczba procesów kręci się stale wokół 600, tylko proces mysql wskazuje, że wykorzystuje do 100% CPU, a nawet do ca 130 % (?). Gdzie szukać przytkania? Parametry Linuxa? Apacha? mysql? sieć wokół serwera? Coś innego? Jest to już III generacja serwerów robiących to samo, bo ciągle zwiększa się obciążenie, a nie wiemy za co się złapać, choć wydawałoby się, że doświadczenia zdobytego przez lata mamy w nadmiarze.

[Gość patrys]

W sumie to nie ten dział...

Nie wiem czemu podałeś parametry starego serwera, a nowego już nie.

Raczej nikt nie wywróży co się stało, na to składa się kilka czynników, również nie podałeś co to obsługuje.

Jest to już III generacja serwerów robiących to samo, bo ciągle zwiększa się obciążenie, a nie wiemy za co się złapać, choć wydawałoby się, że doświadczenia zdobytego przez lata mamy w nadmiarze.

Może poszukać problemu, a nie zmieniać sprzęt nie wyciągając wniosków i kupując jedynie nowości z katalogu intela.

[zanik 0]

patrys, źle zrozumiałeś. Podałem stary, bo konfiguracja była pod ręką. Nowy to praktycznie to samo, tylko szybszy bo, poprzedni był pożyczony i poniewaz przez miesiąc sprawdziła sie jego wydajność, wypożyczony wraca do właściciela, a własny przejął pracę. Jedyna zmiana to x3650M2 zamiast x3500M2 i dwa dyski więcej. Software ten sam i instalacja ta sama, stąd problem, bo jak wszystko takie samo, to gdzie szukać przytkania? Nie szukam gotowego rozwiązania, tylko sugestii, w którym miejscu przytkanie jest najbardziej prawdopodobne, bo może ktoś się już z czyms takim spotkał.

[Gość patrys]

Co się przytyka ?

Pokaż tych kilka linii: # vmstat 1 | head -n 20

I co mysql mówi: # mysqladmin status

I sprawdź sieć czy nie ma strat, wysyceń.

[theONE 526]

daj konfiguracje nowego

 

update:

tak patrze na te 130 % zużycia CPU, to turbo boost w Xeonach nowych, ale sprawia problemy systemowi

 

Sugeruje porównanie ustawień procesorów w biosach, wyłączenie HT i virtualizacji jeżeli nie są potrzebne, wyłączyć oszczędności prądu

jeżeli przeszliście na 56xx koniecznie update BIOSu

 

Druga droga szukania problemu to złe obsadzenie banków pamięci, w 55xx i 56xx powinno się obsadzać po 3 banki na procesor (identyczne kości), trzeba do dokumentacji płyty się odwołać...

[tomii 0]

A może kontrolery dysków się bardzo różniły ?

[theONE 526]

Albo masz dyski z dwoma roznymi wersjami softu i kontroler ma z nimi problem

[ahes 83]

Bez zalogowania się na waszą maszynę ciężko powiedzieć, ale z opisu wygląda mi to na:

 

Korzystacie z XFS i ktoś zapomniał dodać 'nobarrier' w /etc/fstab przy opcjach filesystemu.

 

Jeśli nie to mogę na to rzucić okiem. Kontaktu szukaj w stopce.

[Gość patrys]

Korzystacie z XFS i ktoś zapomniał dodać 'nobarrier' w /etc/fstab przy opcjach filesystemu.

hmm raczej myślę, że jednak jest to ext3, wspomniana opcja do xfs nie ma racji bytu na serwerze produkcyjnym bez modułu bateryjnego w kontrolerze

Sam system plików na pewno nie jest aż tak wielkim wąskim gardłem

 

Zlećcie jakiejś "kumatej" firmie by sprawdziła ten serwerek.

[ahes 83]

hmm raczej myślę, że jednak jest to ext3, wspomniana opcja do xfs nie ma racji bytu na serwerze produkcyjnym bez modułu bateryjnego w kontrolerze

Sam system plików na pewno nie jest aż tak wielkim wąskim gardłem

 

Oj tam, oj tam moduły bateryjne. Dawałem rade z nobarrier i z włączonym write cachem na kontrolerze. Oczywiście jak prąd zniknie to system wymaga xfs_repaira, co przy terabajtowych partycjach trochę trwa. Ale...

 

Jak często znika ci prąd w maszynie w datacenter? Jeśli nie ufamy datacenter, bo awarie się zdarzają (wystarczy sobie przypomnieć jak wyleciał jeden z dużych węzłów AMS-IX, bo siadł główny UPS, a generator nie zaskoczył) to lepiej zainwestować w UPSa 1U, aby przytrzymał w razie czego kilka maszyn. No i backupy trzeba robić i być przygotowanym na czarną godzinę

 

Bariersy zabijaj wydajność i to dość konkretnie:

zapisy do bazy na SSD: 50/s

zapisy z nobarrier: 5300/s

 

No ale zapewniają spójność danych na najwyższym poziomie, co w niektórych systemach ma fundamentalne znaczenie.

[ahes 83]

hmm raczej myślę, że jednak jest to ext3

 

Jest to ext4, a tam już nobarrier istnieje

[zanik 0]

Żeby zakończyć ten temat. Problem został rozwiązany.

Po pierwszym dniu mało udanej eksploatacji serwera, zmianie miały ulec pewne parametry systemu. Osoba wprowadzała zmiany, ale nie wszystkie zostały zapisane, bo prawdopodobnie inna osoba miała otwarty plik konfiguracyjny i nadpisała właściwy. Przez następne kilka dni szukaliśmy przyczyny małej wydajności serwera w przekonaniu, że parametry ustawione są właściwie wg wcześniejszego założenia. W końcu ujawniliśmy, że parametr MaxClient ma wielkość 256, a powinien wg naszych założeń być wyższy. Po jego zmianie zgodnie z założeniami, parametry wydajnościowe nowego serwera odpowiadają tym, osiągaliśmy na x3500, a nawet je przekraczają. Średni czas reakcji na zapytanie z sieci w szczycie wieczornym spadł z kilkunastu sekund poniżej 0,1 sek, co nas satysfakcjonuje.

Dziekuję za wyrażne rady i sugestie.