Dziwny load apache

[Jarosław Szmańda 42]

Cześć,

 

Od jakiegoś czasu mam dziwny problem, co kilka dni load systemu idzie na 33 - z wina apache'a.

 

Restart naprawia problem - lecz skąd on się bierze? W logach nic nie widać... Może coś przeoczyłem.

 

Jeśli ktoś z Was mógł by spojrzeć w nie i naprowadzić na problem będę wdzięczny.

 

 

http://wartozobaczyc.eu/ac.txt

http://wartozobaczyc.eu/error.txt

 

Os - Debian 4, apache z repo - na bieżąco aktualizowany.

 

Dzięki!

[Gość N3T5kY]

Modphp czy fcgi?

[Jarosław Szmańda 42]

Modphp.

[Miłosz 2311]

może jakiegoś flooda dostajesz? slowloris?

[Gość N3T5kY]

Jak masz za duzo polaczec, mod php lubi sie doforkowac

[Jarosław Szmańda 42]

No właśnie w logach za bardzo nie ma o tym... Oglądalności aż tak ogromnej tez nie ma - dlatego nie wiem skąd te anomalie...

[Dariusz Cieślak 3]

Od jakiegoś czasu mam dziwny problem, co kilka dni load systemu idzie na 33 - z wina apache'a.

 

Restart naprawia problem - lecz skąd on się bierze? W logach nic nie widać... Może coś przeoczyłem.

Nie wspomniałeś, że Twój system siedzi na VPS-ie (a zapewne tak jest). "CPU usage - by week" wskazuje, że coś złego dzieje się z hostem. Procesy czekają na normalny dostęp do CPU i go nie dostają - stąd duży load. Dostępny procesor znacznie się zmniejsza.

 

Proponuję kontakt z dostawcą VPS-a (hitme jak widzę), jeśli to nie pomoże zmiana na inną firmę.

 

Nie znam szczegółów implementacji OpenVZ, może jacyś specjaliści się wypowiedzą na ten temat (co może aż w takim stopniu blokować CPU).

 

Korekta: oglądałem czas restartu maszyny, stąd błedne wnioski. Ewidentnie Apache ssie CPU. Brakuje wykresu aktywności sieci (czy przyczyna jest zewnętrzna). Być może jest to zapętlenie w skrypcie PHP. Proponuję znacznie zmniejszyć timeout i wprowadzić watchdoga który przy wysokim load automatycznie zarejestruje stan systemu (lsof, ps itp) i zrestartuje apache. To powinno pomóc zdiagnozować problem.

[Jarosław Szmańda 42]

Chodzi o ten timeout:

 

#

# Timeout: The number of seconds before receives and sends time out.

#

Timeout 10

? Jeśli tak, to od dawna tak ustawiony jest. Dodatkowo mam:

KeepAliveTimeout 1

 

W php.ini timeout na 60 s ustawiony - jego też zmniejszyć?

; Default timeout for socket based streams (seconds)

default_socket_timeout = 60

 

Co do tego watchdog'a - mógł byś napisać coś więcej?

[Dariusz Cieślak 3]

Jeśli tak, to od dawna tak ustawiony jest.

 

Jeśli PHP się zapętla to potrzebujesz ograniczyć maksymalny czas generowania odpowiedzi przez skrypt. Czy to jest ta dyrektywa tego nie wiem - należy poszukać w dokumentacji.

 

Co do tego watchdog'a - mógł byś napisać coś więcej?

 

Jeśli mam na serwerze jakiś "losowy" problem to potrzebuję zrobić dwie rzeczy:

 

• Zdiagnozować problem
  
• Ograniczyć straty
  

 

Diagnostyka problemu: skrypt w momencie detekcji problemu (wysoki load, MySQL niedostępny, wchodzenie systemu w swap itp) zapisuje stan systemu który może być przydatny do diagnostyki do pliku.

 

Ograniczenie strat (braku dostępu do systemu): automatyczny restart usług po pobraniu danych.

 

Typowo piszę mały dedykowany skrypt w bashu-u i umieszczam go w cronie (np. co 5 minut). Wtedy maks. czas niedostępności systemu ograniczam do 5 minut a sobie zostawiam możliwość późniejszej analizy co się stało i finalnego naprawienia błędu.

 

Prosty przykład: automatyczne ubijalnie procesów FastCGI którym wycieka pamięć:

 

*/5 * * * * ps xv | awk '/\.fcgi/ { if($8>35000) print "kill", $1 }' | sh