Mam problemy z ładowaniem serwera i chociaż jestem nieco doświadczonym administratorem Linuksa, nie mam już pomysłów.
Problemem jest powolne, ale stale rosnące obciążenie serwera bez wyraźnej przyczyny.
Serwer to dwurdzeniowy procesor AMD Athlon (tm) 64 X2 6000+ z 6 GB pamięci RAM. Działa pod kontrolą Debiana Stable z systemem Linux gir 2.6.26-2-amd64 # 1 SMP Środa 19 sierpnia 22:33:18 UTC 2009 x86_64 GNU / Linux.
Serwer zasadniczo obsługuje Lighttpd, kilka procesów PHP FastCGI i bazę danych MySQL. Typowe zadania serwera WWW.
Procesor nigdy tak naprawdę nie jest w pełni wykorzystany, a pamięć jest wykorzystywana głównie na bufory i pamięć podręczną, co jest w porządku. Próbowałem ponownie uruchomić różne usługi, aby sprawdzić, czy jedna z nich ponownie zmniejszy obciążenie, ale bez powodzenia.
Oto grafika przedstawiająca obciążenie, procesor i IOStat:
Pytanie zatem brzmi: co może powodować powolne, ale wciąż rosnące obciążenie? Jak mogę dowiedzieć się, co jest za to odpowiedzialne?
Aktualizacja: zapomniałem wspomnieć, że po ponownym uruchomieniu serwera obciążenie spadnie do około 0,3 do 0,6 i zacznie się powoli wspinać w kolejnych tygodniach.
Odpowiedzi:
Każdy proces zombie dodaje 1,0 do obciążenia. Być może widzisz nagromadzenie zombie.
źródło
for N in {1..100} ; do sleep 60 & done ; exec sleep 500
powinno wystarczyć, aby spowodować duże obciążenie. Ale tak nie jest. To polecenie powoduje 100 zombie, ale obciążenie mojego komputera pozostało poniżej 1.Znalazłem doskonałą wskazówkę w odpowiedzi na inne pytanie .
Poszukiwanie procesów w stanie „D” pokazuje cztery procesy PHP, które wydają się zawieszać przez dłuższy czas, odpowiadające „krokom” na krzywej obciążenia:
To wydaje się być problemem. Muszę się teraz dowiedzieć, kiedy te procesy się zawieszają i jak to naprawić. Dziękuję wszystkim.
źródło
Domyślam się, że serwer jest głodny IO, może powinieneś dodać statystyki iotop do wykresów
Zastanawiam się, czy możesz mieć aktywność io na aplikację, która jest również czynnikiem obciążającym serwer
http://rt.wiki.kernel.org/index.php/I/Otop_utility
innym narzędziem jest dstat
źródło
Gdyby to było We / Wy, zobaczyłby iowait (różowy) na wykresach procesora.
źródło
Tego rodzaju problemy często wynikały z dysku twardego, który nie jest wystarczająco szybki, aby obsłużyć dane wymagane przez bazę danych MySQL i serwer HTTP. Powinieneś spojrzeć na komendę iostat
źródło
Zasadniczo wysokie obciążenie serwera nie jest wcale takie złe; oznacza to, że nie siedzisz bezczynnie i robisz mniej, niż mógłbyś inaczej. 80% -90% obciążenia twojej całkowitej pojemności (z pewnym pokojem „wybuchowym”) jest tym, czego zwykle się szuka. Polecam sprawdzenie danych wyjściowych mpstat i vmstat. W szczególności pierwsze 2 liczby z vmstat mogą dostarczyć bardziej znaczących informacji o tym, jak „utworzono kopię zapasową” pod względem procesów w kolejce uruchamiania. Ostatnia kolumna („wa”) danych wyjściowych vmstat może powiedzieć, czy i jak długo czekasz na zakończenie operacji we / wy. Rozmiar kolejki uruchamiania i czas oczekiwania we / wy są często skorelowane. Sprawdź także sar (z pakietu sysstat): to daje szczegółowy widok tego, co dzieje się w pewnym okresie czasu; rejestrowane przez niego dane są bardzo dokładne.
źródło