Vraag apache webserver reageert niet meer en de server-status toont alle onderliggende processen die wachten op verbinding


Mijn setup: Ik heb 3 bijna identieke webserver-machines die dezelfde dynamische dynamische website bedienen met eenvoudige load-balancing over dns. De service werkt al meer dan twee jaar met dezelfde apache-configuratie. apache2, php5, ubuntu 8.04 linux 2.6.24-29-server

Mijn probleem: sinds ongeveer twee weken heb ik problemen met deze configuratie. Bijna elke dag heb ik een klein moment ongeveer 5 minuten, waarin de website onbereikbaar is. Ik kan nog steeds inloggen op de servers via ssh. Als ik op topniveau ren, zie ik dat de machine gewoon niets doet. ik heb ongeveer 1000 apache-processen lopen, maar geen cpu-activiteit.

ik heb de apache mod_status gebruikt om deze situatie te debuggen. het processcorebord ziet er als volgt uit:

_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

Dus de meeste processen wachten gewoon op verbinding. na ongeveer 5 minuten zal de situatie weer normaal worden: ik heb de minste processen op elke machine, de meeste werknemers hebben de "." - status (ze mogen een aanvraag behandelen) en de website is natuurlijk bereikbaar!

dus ik probeer iets in de logs te vinden, maar er is gewoon niets ... het apache toegangslog is ongeveer 4 minuten stil, hetzelfde geldt voor het foutenlogboek. ik kan ook niet begrijpen dat er iets mis is in andere systeemlogboeken.

de situatie is hetzelfde op alle 3 webservers (ze hebben allemaal tegelijkertijd deze belastingspiek en niet-reagerende toestand), dus ik denk niet dat dit hardware-gerelateerd is. maar ik denk dat dit te maken kan hebben met een bepaald netwerk (tcp) probleem.

ideeën?

BEWERK: wat meer informatie, die ik zojuist heb ontdekt:

het is net weer gebeurd. en ik kon verifiëren dat ik ook lokaal geen verbinding kan maken wanneer dit probleem voorkomt. Ik heb wat verbindingsstatistieken gemaakt met de volgende opdracht nadat dit is gebeurd netstat -an | awk '/ tcp / {print $ 6}' | sort | uniq -c

  • 109 CLOSE_WAIT
  • 2652 GEVESTIGD
  • 2 FIN_WAIT1
  • 11 LAST_ACK
  • 12 LUISTER
  • 91 SYN_RECV
  • 1 SYN_SENT
  • 16 TIME_WAIT

Als ik later hetzelfde commando uitvoer, heb ik zoiets als dit:

  • 4 SLUITEN
  • 108 GEVESTIGD
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LAST_ACK
  • 12 LUISTER
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Dus in de normale situatie heb ik slechts 100-200 open verbindingen door clients die op dit moment door apache worden behandeld. wanneer ik deze "crash" heb, heb ik veel meer verbindingen. Wat is de beste manier om dit te analyseren?

EDIT2: de belangrijke regels in apache2.conf zijn:

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

het is een apache2 prefork met php_mod.

de server heeft 8GB RAM en een 4GB swappartitie.


8
2018-01-31 12:24


oorsprong


Toont de website dezelfde symptomen wanneer u een wget of curl uitvoert vanaf de lokale host of tussen servers (als deze zich op hetzelfde netwerk bevinden)? - Alex Forbes
Misschien een verkeersdump (tcpdump) zal je helpen om de oorzaak van het probleem te vinden ... trouwens, wat is je geheugengebruik en firewallbeleid? - drcelus
@ al4 de laatste keer dat dit gebeurde, kon ik verbinding maken met de serverstatuspagina van de lokale host, terwijl ik geen verbinding kon maken met de webpagina van buitenaf. ik ben er niet helemaal zeker van, want het kan ook een willekeurig iets zijn, terwijl een deel van de werkers beschikbaar kwam. ik zal dit nog een keer testen als het probleem zich voordoet. wat zou uw suggestie zijn, als ik enig verschil zou kunnen bevestigen tussen externe en lokale verbindingen? - Jeff
Als je kunt bevestigen dat het lokaal werkt, maar niet van buitenaf, wordt het duidelijk dat het probleem het probleem is. Je moet dus testen met tcpdumps en wireshark aan beide kanten om te zien wat er aan de hand is, in plaats van de apache-processen af ​​te schrikken. Ik zou ook testen van een host op hetzelfde LAN indien mogelijk. En controleer dmesg om te zien of er berichten zijn die gerelateerd kunnen zijn, maar het klinkt alsof je dat al hebt gedaan. - Alex Forbes
het is net weer gebeurd. en ik kon verifiëren dat ik ook lokaal geen verbinding kan maken wanneer dit probleem voorkomt. ik heb ook een aantal verbindingsstatistieken met netstat gemaakt: zie de vraagtekst - Jeff


antwoorden:


Ten eerste: Controleer uw Max open files limiet op het proces. Een actieve socketverbinding telt als een open bestand. cat /proc/###/limits is een goede manier om de effectieve waarde voor een ander proces te controleren. U kunt een lijst met geopende bestanden krijgen met lsof -p ### waarbij ### de proces-ID van uw webserver is. Je kunt het vergelijken lsof -p ### | wc -lom te zien hoe dicht je bij de limiet komt. Je zou ook berichten in apache's error_log moeten zien als je de limiet bereikt.

U hebt een bestandshandvat nodig voor elke socketverbinding en ook voor elk cgi-script of gegevensbestandreferentie. Voor 920 MaxClients moet u ten minste 4.000 bestanden configureren voor het httpd-proces. U kunt het aantal bestanden verhogen door een bestand toe te voegen in /etc/security/limits.d/ met de volgende inhoud. Zorg ervoor dat de gebruikersnaam overeenkomt met wat u gebruikt voor uw webserver.

apache soft nofile 10000
apache hard nofile 10000

Ten tweede: Als poortuitputting uw probleem is, kunt u de sommige IP-instellingen in /etc/sysctl.conf aanpassen. (Beginnend met net.ipv4.tcp_fin_timeout). Dit is meestal alleen een probleem met heel veel zeer kleine verbindingen. Veel TIME_WAIT-sockets is hier een indicator van, maar dit geeft poortuitputting alleen aan als deze gepaard gaat met fouten in syslog over possible SYN flooding en Sending cookies. Zorg er ook voor dat uw server zich achter een firewall bevindt die schadelijke SYN-aanvallen kan tegenhouden.


1
2017-12-26 05:21





U moet de uitgebreide status van mod_status inschakelen (http://httpd.apache.org/docs/2.2/mod/mod_status.html#extendedstatus) om de huidige hosts en verzoeken die worden verwerkt te controleren. Ik denk dat er een script (s) / pagina ('s) is die te lang duurt om de verbinding vrij te maken en de verbindingen stapelen.


1
2018-03-04 18:40





Toon uw apache MPM-instellingen en keepalive-instellingen.

Het is waarschijnlijk een slechte combinatie hiervan.

EDIT: Ik zag dat je php noemde.

Als dit mod_php is dat u gebruikt, heeft die machine beter 64 GB geheugen of kunt u nooit 2500 verbindingen maken.


0
2018-02-01 14:17



ik heb de apache config aan de vraag toegevoegd. ik weet niet hoe dit het accepteren van verbindingen zou kunnen beïnvloeden, maar de MaxClients-instelling is echt te hoog ingesteld. ik heb dit gecontroleerd: mijn apache-medewerkers nemen meestal 15 - 30 MB RAM. Denk je dat de hogere instelling zo'n effect zou kunnen hebben? - Jeff
Ik heb de ServerLimit en MaxClients teruggebracht naar 500. sindsdien is het probleem twee keer opnieuw opgetreden. gedurende ongeveer 4 minuten heb ik geen activiteit in mijn apache log op alle drie de servers en de website is niet bereikbaar! dus de ServerLimit was niet het punt ... - Jeff


Houd er ook rekening mee dat in het prefork MPM elk proces PHP in zijn geheugenruimte heeft (wat is zijn geheugenlimietinstelling?). Misschien wil je proberen over te schakelen naar de MPM van de werknemer, waarvoor je misschien een iets andere PHP-module nodig hebt.

Ook de moeite waard om een ​​externe oorbel te gebruiken om je Apache-configuratie van externe modules te trimmen

In mijn ervaring worden dergelijke dingen veroorzaakt door zaken als een crawler voor zoekmachines, of dingen zoals ARP-conflicten. Of verkeersniveaus in een bepaald gerelateerd deel van het netwerk.

Misschien vind je 'sar' wel handig ... niet het meest vriendelijke, maar zeker handig.

Mogelijk ook io gerelateerd. Sar kan je vertellen (als je het configureert om schijfactiviteit op te nemen), wat de gemiddelde io-wachttijd is. Je kunt ook kijken naar de IO Wachttijd bovenaan (dit is een percentage, lees wat het eigenlijk betekent). Dit kan aanzienlijk zijn als u een SAN of een virtuele omgeving gebruikt.


0
2018-05-09 08:33