ustawienie Apache, Mysql dla dużego obci

[marecek]

Witam na forum i od razu zadam pytanie...

Codziennie w okolicy 21.30 serwer przestaje odpowiadać. Problem wiążę niewątpliwie z wysokim obciążeniem, jednak nie wiem w jaki sposób sobie z tym poradzić.

Ale po kolei:

serwer to Debian 4.0, Linux xxx 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64. MySQL obsługuje dwie duże bazy danych (kilkanaście mln. rekordów, każda waży ok. 1GB) - są to fora vbulletin. Do dyspozycji mam 4GB pamięci.

Z chwilą wybicia godziny "zero" webmin pokazuje mi coś takiego:


(przepraszam za obrazki, ale nie umiem jeszcze po prostu inaczej zaobserwować tego zachowania - wszelkie logowanie "staje" z chwilą wystąpienia problemu).

Pierwszą rzeczą, której spróbowałem była aktualizacja apache'a (Apache/2.2.3) i mysqla (5.0.32-Debian_7etch6-log). Później wertowanie for vbulletin.com w poszukiwaniu jakichś zoptymalizowanych konfiguracji mysqla. Nie pomogło... zawsze jak większa grupa ludzi wparuje na serwer to sytuacja wygląda tak jak na powyższych obrazkach.

Jedynym rozwiązaniem jest zalogować się (odczekać swoje) i zrestartować apache'a (też odczekać). Po tym problem "opada" i wszystko się stabilizuje. Stąd mój wniosek, że problem leży gdzieś na styku apache i mysql. Tylko gdzie? Jak to zlokalizować i co ewentualnie naprawić?

Macie jakiś pomysł jak to ugryźć? Skoro jest jakiś fizyczny limit, to czy nie dałoby się klientów odprawiać z "kwitkiem" albo wrzucić ich do jakiejś kolejki?

[lessmian2]

Zauważ że w czasie "przeciążenia" bardzo wzrasta iowait na pierwszym wykresie. Mogło by to sugerować że w tym czasie coś bardzo jeździ po dyskach. Jaki masz podsystem dyskowy? Jakaś macierz, RAID? Nie masz czasem ustawionego na ten czas backupu danych (np MySQL-a?). Mógłbyś jeszcze zapodać jakiś wykres z ilością uzytkowników via WWW w tym czasie.

[marecek]

Moje wnioski były podobne. Ale żadne kopie zapasowe nie są robione o tej porze (pierwsza kopia leci wg crona o 23.23). System dyskowy to serial ata. Bazy leżą na dedykowanym dysku (nie partycji - jest to niezależny dysk), system i www-data na drugim dysku.

W jaki sposób najszybciej zmierzyć ilość użytkowników? Apache ma ustawiony ,,maxclients'' na 250 i nie występuje sytuacja, w której wszystkie gniazda są zajęte (przynajmniej podglądając na żywo na http://adres/server-status). W jaki inny sposób powinienem to diagnozować?

Edit:
Jestem nowy i nie widać nie bardzo rozumiem zasady tu panujące, ale... dlaczego ktoś edytował mi pierwszego posta robiąc pogrubionym tekstem wyrazy "przepraszam" i "aktualizacja"?

[chyl-o]

Sprawdź czasy wykonywania skryptów, do konfiguracji vhostów dodaj do custom loga "%t %D %r %O"

Potem przejrzyj zainstalowane dodatki, czysty vbuiletin jest dosyć szybki, ale niektóre dodatki potrafią zabić, sam miałem podobną sytuację na jednym serwerze - również duży serwis i spora baza, wykonywanie skryptu oscylowało w okolicach 1.5 - 2 sekund, po odinstalowaniu jednego dodatku(bij zabij nie pamiętam jakiego) czasy zeszły do ~0.5s.

Możesz również zainstalować APC - wbrew pozorom nawet skrypty które bezpośrednio go nie używają zaczynają wykonywać się szybciej.

[marecek]

Zrobiłem "własny log" (ang. custom log) zgodnie z zaleceniami. Do czasu wystąpienia awarii wszystkie skrypty generują się błyskawicznie (rzędu kilkunastu-kilkudziesięciu milisekund - przez okrągły dzień, aż do godziny 21 z minutami). W okolicy 21. nagle wszystkie skrypty php zaczynają się wykonywać w czasie 20-30-100-400 sekund i wszystko staje... Jak na wymienionym przykładzie.

Przeniosłem mniejszą z dwóch bazę danych na partycję systemową - może to wykluczy temat wydajności dysku.

Jedna rzecz, której nie powiedziałem wcześniej to to, że z chwilą wystąpienia awarii, jestem zasypywany setkami wiadomości pocztowych (email) z vbulletin-a, w których pojawia się informacja o błędzie bazy danych (mysql) - zbyt wiele połączeń (ang. too many connections). Co wydaje mi się dziwne, bo do tej pory wydawało mi sie, że na styku apache / mysql jest tylko jedno połączenie (aktualnie max_connections = 222).

Jak to interpretować? Będę wdzięczny za jakiekolwiek sugestie.

[chyl-o]

Jedna rzecz, której nie powiedziałem wcześniej to to, że z chwilą wystąpienia awarii, jestem zasypywany setkami wiadomości pocztowych (email) z vbulletin-a, w których pojawia się informacja o błędzie bazy danych (mysql) - zbyt wiele połączeń (ang. too many connections). Co wydaje mi się dziwne, bo do tej pory wydawało mi sie, że na styku apache / mysql jest tylko jedno połączenie (aktualnie max_connections = 222).

Jak to interpretować? Będę wdzięczny za jakiekolwiek sugestie.

Możesz się zalogować na shella mysql'a(z prawami administratora) i tam sprawdzić ile masz aktualnych połączeń:

Kod: Zaznacz cały

show processlist]

Nie musisz się martwić o połączenie, ponieważ mysql zawsze rezerwuje jedno dla administratora.

// edit: możesz również zwiększyć ilość możliwych połączeń z serwerem w konfiguracji mysql'a.

[marecek]

Ok, zrobiłem trzy rzeczy:

1. zwiększyłem ilość połączeń dla SQLa (z 222 do 444)
2. przeniosłem mniejszą z baz na dysk systemowy
3. ustawiłem crawl-delay w pliku robots.txt na 120 dla każdego z for

Któreś z tych trzeba ustawień zadziałało, bo dzisiejsze obciążenie wygląda perfekcyjnie (60-70% zajętości procesora przy minimalnym Io-Wait rzędu 2-5% przez cały wieczór, bez żadnych "skoków" obciążenia).

Co do procesów aktywnych na SQLu, to zawsze mam dwóch użytkowników baz, siebie grzebiącego w phpMyAdminie (show processlist) i kilkunastu użytkowników serwera pocztowego. Wniosek, jaki tu wyciągam jest taki, że opcja nr 1. w ogóle nie wpłynęła na zachowanie serwera...