serwer Apache nie odpowiada ze statusem serwera pokazującym wszystkie procesy potomne oczekujące na połączenie [zamknięte]

Moja konfiguracja: mam 3 prawie identyczne maszyny do serwerów WWW obsługujące tę samą, wysoko obciążoną dynamiczną stronę internetową z prostym równoważeniem obciążenia przez dns. Usługa działa od ponad dwóch lat z tą samą konfiguracją apache: apache2, php5, ubuntu 8.04 linux 2.6.24-29-server.

Mój problem: od około dwóch tygodni temu mam problemy z tą konfiguracją. Niemal każdego dnia mam jedną krótką chwilę przez około 5 minut, w której strona jest niedostępna. Nadal jestem w stanie zalogować się do serwerów przez ssh. Po uruchomieniu htopwidzę, że maszyna nic nie robi. Mam uruchomionych około 1000 procesów Apache, ale nie mam żadnej aktywności procesora.

Użyłem apache mod_status do debugowania tej sytuacji. Tabela wyników procesu wygląda następująco:

_C.___K_______________________R._______.__K_K____K___C_______.__
_______C__________.___________________________________.________C
_.____K__________K___K_WK_____._K_____________________________._
W______K__________K________.____________________._______C_______
_C_.__K__K____.._.._____________________________________C_______
_R___________K___.______C________.C_________.______._____C______
____________KKC____K_____K__WC_________________C_____.__.____.__
_____________________C_________K______.____C______._____________
_.___C____.___.___________________________.K______.____K________
W__.___________________C.__.____K________K_______R_._.__._______
__C__C_.__________C__C_______._____W______________C_.___C_______
____.______C_____________C________.____C____________.________._K
__.__________.K_____________K_________._____C____.K__________KW_
__K.W________R_________._______.___W___________.____.__K_____W__
W___.___..________W____K

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

Większość procesów tylko czeka na połączenie. po około 5 minutach sytuacja wróci do normy: na każdym komputerze mam dużo mniej procesów, najwięcej pracowników ma status „.” (co oznacza, że ​​są otwarci na przetworzenie żądania) i oczywiście strona jest dostępna!

więc próbuję znaleźć coś w dziennikach, ale po prostu nie ma nic ... dziennik dostępu apache milczy przez około 4 minuty, to samo dotyczy dziennika błędów. Nie mogę też znaleźć niczego złego w innych logach systemowych.

sytuacja jest taka sama na wszystkich 3 serwerach WWW (wszystkie mają ten szczyt obciążenia i stan braku odpowiedzi w tym samym czasie), więc nie sądzę, że jest to związane ze sprzętem. ale myślę, że może to być związane z jakimś problemem z siecią (TCP).

jakieś pomysły?

EDYCJA: kilka dodatkowych informacji, które właśnie odkryłem:

To się powtórzyło i byłem w stanie zweryfikować, że nie jestem w stanie połączyć się lokalnie, gdy wystąpi ten problem.

Po tym, jak to się stało, utworzyłem statystyki połączeń za pomocą następującego polecenia: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

• 109 CLOSE_WAIT
• 2652 USTANOWIONO
• 2 FIN_WAIT1
• 11 LAST_ACK
• 12 POSŁUCHAJ
• 91 SYN_RECV
• 1 SYN_SENT
• 16 TIME_WAIT

Jeśli jakiś czas później wykonam to samo polecenie, mam coś takiego:

• 4 ZAMYKANIE
• 108 USTANOWIONO
• 18 FIN_WAIT1
• 182 FIN_WAIT2
• 37 LAST_ACK
• 12 POSŁUCHAJ
• 50 SYN_RECV
• 11276 TIME_WAIT

Więc w normalnej sytuacji mam tylko 100-200 otwartych połączeń przez klientów obsługiwanych przez apache w tym momencie. Kiedy mam tę „awarię”, mam o wiele więcej połączeń. Jak najlepiej to przeanalizować?

EDYCJA 2: ważne wiersze w apache2.conf to:

KeepAlive On
MaxKeepAliveRequests 20
KeepAliveTimeout 1
<IfModule mpm_prefork_module>
ServerLimit           920
StartServers          30
MinSpareServers       80
MaxSpareServers      120
MaxClients          920
MaxRequestsPerChild   700
</IfModule>

Jest to prefork apache2 z php_mod.

Serwer ma 8 GB pamięci RAM i partycję wymiany 4 GB.

Należy włączyć rozszerzony status mod_status ( http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus ) w celu monitorowania bieżących hostów i przetwarzanych żądań. Wydaje mi się, że istnieje skrypt (y) / strona (strony), które zwalniają połączenie zbyt długo i powoduje to, że połączenia się układają.

Po pierwsze: sprawdź swój Max open fileslimit procesu. Aktywne połączenie przez gniazdo liczy się jako otwarty plik. cat /proc/###/limitsto dobry sposób na sprawdzenie wartości skutecznej dla innego procesu. Możesz uzyskać listę otwartych plików, w lsof -p ###których ### jest identyfikatorem procesu twojego serwera WWW. Możesz porównać, lsof -p ### | wc -laby zobaczyć, jak bardzo zbliżasz się do limitu. Powinieneś również zobaczyć komunikaty w dzienniku błędów dziennika Apache, jeśli osiągasz limit.

Potrzebujesz uchwytu pliku dla każdego połączenia gniazda, a także dla każdego skryptu cgi lub odwołania do pliku danych. W przypadku 920 MaxClients należy skonfigurować co najmniej 4000 plików dla procesu httpd. Możesz zwiększyć liczbę plików, dodając plik w /etc/security/limits.d/ o następującej treści. Upewnij się, że nazwa użytkownika odpowiada temu, czego używasz na swoim serwerze internetowym.

apache soft nofile 10000
apache hard nofile 10000

Po drugie: jeśli problem stanowi wyczerpanie portów, możesz dostosować niektóre ustawienia ip w /etc/sysctl.conf. (Począwszy od net.ipv4.tcp_fin_timeout). Jest to zwykle problem tylko w przypadku bardzo małych połączeń. Wiele gniazd TIME_WAIT jest tego wskaźnikiem, ale wskazuje to na wyczerpanie portów tylko wtedy, gdy towarzyszą im błędy w syslog dotyczące possible SYN floodingi Sending cookies. Należy również upewnić się, że serwer znajduje się za zaporą ogniową, która może udaremniać złośliwe ataki SYN.

Pamiętaj również, że w prefork MPM każdy proces będzie miał PHP w swoim obszarze pamięci (jakie jest ustawienie limitu pamięci?). Możesz spróbować przejść na roboczy MPM, który może wymagać nieco innego modułu PHP.

Warto również zdalny kolczyk, aby przyciąć konfigurację zewnętrznych modułów Apache

Z mojego doświadczenia wynika, że ​​takie rzeczy są wywoływane przez rzeczy takie jak wyszukiwarka lub konflikty ARP. Lub poziomy ruchu w niektórych powiązanych częściach sieci.

Może się okazać, że „sar” jest użyteczny ... nie najbardziej przyjazny, ale na pewno użyteczny.

Być może również związane z io. Sar może ci powiedzieć (jeśli skonfigurujesz go do rejestrowania aktywności na dysku), jaki jest średni czas oczekiwania io. Możesz także spojrzeć na czas oczekiwania IO na górze (który jest procentem, przeczytaj, co to właściwie oznacza). Może to być znaczące, jeśli korzystasz z sieci SAN lub środowiska wirtualnego.