server web apache non risponde con lo stato del server che mostra tutti i processi figlio in attesa di connessione [chiuso]


10

La mia configurazione: ho 3 macchine server web quasi identiche che servono lo stesso sito Web dinamico ad alto carico con un semplice bilanciamento del carico su DNS. Il servizio funziona da oltre due anni con la stessa configurazione di apache: apache2, php5, ubuntu 8.04 linux 2.6.24-29-server.

Il mio problema: da circa due settimane ho riscontrato problemi con questa configurazione. Quasi ogni giorno ho un piccolo momento per circa 5 minuti, in cui il sito Web è irraggiungibile. Sono ancora in grado di accedere ai server tramite ssh. Se corro htop, vedo la macchina semplicemente non fare nulla. Ho circa 1000 processi Apache in esecuzione, ma nessuna attività della CPU.

Ho usato apache mod_status per eseguire il debug di questa situazione. Il quadro di valutazione del processo è simile al seguente:

_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

Quindi la maggior parte dei processi sta solo aspettando la connessione. dopo circa 5 minuti la situazione tornerà alla normalità: ho molti meno processi su ogni macchina, la maggior parte dei lavoratori ha lo stato "." (dato che sono aperti per elaborare una richiesta) e ovviamente il sito Web è raggiungibile!

quindi sto cercando di trovare qualcosa nei log, ma semplicemente non c'è nulla ... il log di accesso ad apache è silenzioso per circa 4 minuti, lo stesso vale per il log degli errori. Inoltre non riesco a capire nulla di sbagliato in altri registri di sistema.

la situazione è la stessa su tutti e 3 i server web (tutti hanno questo picco di carico e condizioni non rispondenti allo stesso tempo), quindi non credo che questo sia legato all'hardware. ma penso, questo potrebbe essere correlato ad alcuni problemi di rete (tcp).

qualche idea?

EDIT: alcune ulteriori informazioni che ho appena scoperto:

È appena successo di nuovo e sono stato in grado di verificare che non sono in grado di connettermi localmente quando si verifica questo problema.

Ho fatto alcune statistiche di connessione con il seguente comando dopo che è successo: netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

  • 109 CLOSE_WAIT
  • 2652 STABILITO
  • 2 FIN_WAIT1
  • 11 LAST_ACK
  • 12 ASCOLTA
  • 91 SYN_RECV
  • 1 SYN_SENT
  • 16 TIME_WAIT

Se eseguo lo stesso comando qualche tempo dopo, ho qualcosa del genere:

  • 4 CHIUSURA
  • 108 STABILITO
  • 18 FIN_WAIT1
  • 182 FIN_WAIT2
  • 37 LAST_ACK
  • 12 ASCOLTA
  • 50 SYN_RECV
  • 11276 TIME_WAIT

Quindi nella situazione normale ho solo 100-200 connessioni aperte da parte dei client gestite da Apache in questo momento. Quando ho questo "crash", ho molte più connessioni. Qual è il modo migliore per analizzarlo?

EDIT2: le righe importanti in apache2.conf sono:

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

È un prefork apache2 con php_mod.

Il server ha 8 GB di RAM e una partizione di swap da 4 GB.


Il sito Web mostra gli stessi sintomi quando si esegue un wget o un ricciolo dall'host locale o tra server (se si trovano sulla stessa rete)?
Alex Forbes,

Forse un dump del traffico ( tcpdump) ti aiuterà ad arrivare alla radice del problema ... a proposito di quali sono i tuoi criteri di utilizzo della memoria e firewall?
drcelus

@ al4 l'ultima volta che è successo, sono stato in grado di connettermi alla pagina di stato del server dall'host locale, mentre non ero in grado di connettermi alla pagina Web dall'esterno. non ne sono del tutto sicuro, dato che potrebbe anche essere una cosa casuale, mentre alcuni lavoratori diventano disponibili. lo proverò più la prossima volta che si verificherà il problema. quale sarebbe il tuo suggerimento, se potessi confermare qualche differenza tra connessioni esterne e locali?
Jeff

Se puoi confermare che funziona localmente ma non dall'esterno, rafforza il caso per cui la rete è il problema, il che significa che dovresti testare con tcpdumps e WireShark su entrambe le estremità per vedere cosa sta passando, piuttosto che strassare i processi di Apache. Proverei anche da un host sulla stessa LAN, se possibile. E controlla dmesg per vedere se ci sono messaggi che potrebbero essere correlati ma sembra che tu l'abbia già fatto.
Alex Forbes,

è appena successo di nuovo. e sono stato in grado di verificare che non sono in grado di connettermi localmente quando si verifica questo problema. ho anche fatto alcune statistiche di connessione con netstat: vedi il testo della domanda
Jeff,

Risposte:



1

Primo: controlla il tuo Max open fileslimite sul processo. Una connessione socket attiva viene considerata come un file aperto. cat /proc/###/limitsè un buon modo per verificare il valore effettivo di un altro processo. È possibile ottenere un elenco di file aperti in lsof -p ###cui ### è l'ID di processo del server Web. Puoi confrontare lsof -p ### | wc -lper vedere quanto ti avvicini al limite. Dovresti anche vedere i messaggi nel log degli errori di apache se stai raggiungendo il limite.

È necessario un handle di file per ogni connessione socket e anche per ogni script cgi o riferimento al file di dati. Per 920 MaxClients, è necessario configurare almeno 4.000 file per il processo httpd. È possibile aumentare il numero di file aggiungendo un file in /etc/security/limits.d/ con i seguenti contenuti. Assicurati che il nome utente corrisponda a quello che stai utilizzando per il tuo server web.

apache soft nofile 10000
apache hard nofile 10000

Secondo: se il problema è l'esaurimento delle porte, è possibile regolare alcune impostazioni IP in /etc/sysctl.conf. (A partire da net.ipv4.tcp_fin_timeout). Questo di solito è un problema solo con molte connessioni molto piccole. Molti socket TIME_WAIT ne sono un indicatore, ma ciò indica l'esaurimento delle porte solo se accompagnato da errori nel syslog su possible SYN floodinge Sending cookies. Dovresti anche assicurarti che il tuo server sia protetto da un firewall in grado di contrastare attacchi SYN dannosi.


0

Inoltre, tieni presente che nel prefork MPM, ogni processo avrà PHP nel suo spazio di memoria (qual è la sua impostazione del limite di memoria?). Potresti provare a cambiare in MPM worker, che potrebbe richiedere un modulo PHP leggermente diverso.

Vale anche la pena l'orecchino remoto per tagliare la configurazione di moduli estranei Apache

Nella mia esperienza, tali cose sono innescate da cose come un crawler del motore di ricerca o cose come conflitti ARP. O livelli di traffico in alcune parti correlate della rete.

Potresti trovare 'sar' utile ... non il più amichevole, ma sicuramente utile.

Forse anche io correlato. Sar può dirti (se lo configuri per registrare l'attività del disco), qual è il tempo di attesa medio di io. Puoi anche guardare il tempo di attesa IO in alto (che è una percentuale, leggi cosa significa effettivamente). Questo può essere significativo se si utilizza una SAN o un ambiente virtuale.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.