Newsgroup: it.comp.os.linux.sys
Titolo: Timeout saltuari su Apache

Stranamente, da oggi, si verificano dei timeout saltuari durante la connessione ad un server apache. I timeout si verificano anche con una semplice:
 
# curl 
http://127.0.0.1/
 
curl: (7) Failed connect to 
127.0.0.1:80
; Timeout della connessione
 
quindi i dns non sono coinvolti.
 
Apache non logga nulla, secondo lui è tutto regolare.
La pagina che cerco di richiamare non esiste (quindi darebbe un 404) e di conseguenza non viene coinvolto alcun PHP, FastCGI o cose simili
 
Ho provato a disattivare in toto il firewall: stesso risultato
 
Che diavolo può essere? Tempo sia un problema a monte di Apache, ma non saprei causato da chi.

 Che diavolo può essere? Tempo sia un problema a monte di Apache, ma non saprei causato da chi.
 
Aggiungo che il problema, apparentemente, si verifica solo da dentro la macchina.
Dall'esterno non ricevo timeout ma se lo faccio da sopra il server si.


Sembrerebbe un problema di firewall visto che dall' esterno funziona e 
quindi non puo essere la macchina troppo carica
Però non il firewall della macchina visto che hai controllato
Apache puo filtrare in .htaccess  e in varie direttive del file 
configurazione (un grep con Deny Allow sulla configurazione potrebbe 
essere una idea)
 

 essere una idea)
 
Se fosse un problema di .htaccess in primo luogo avrei una risposta da parte del server e non un timeout durante la connessione verso la porta, ed in secondo luogo, ci sarebbe una corrispondenza nei log.
 
Comunque no, l'htaccess non può essere visto che non c'è


E le direttive Allow e Deny ?
 

 E le direttive Allow e Deny ?
 
Come già detto, non può essere un problema di tale tipo perchè:
 
1. se fosse un deny, lo farebbe sempre e non saltuariamente a seconda di come gli gira, tant'è che riprovando dopo un timeout, la richiesta va a buon fine;
 
2. un deny causa comunque un errore HTTP, io invece non riesco nemmeno a connettermi alla porta, non ci arrivo proprio ad L7
 


Se è saltuario allora è la macchina che è troppo carica in alcuni 
momenti oppure un bug del kernel o di apache
 

 momenti oppure un bug del kernel o di apache
 
Se fosse troppo carica, lo sarebbe anche provando da remoto, mentre invece il problema si presenta esclusivamente in locale.


Se è saltuario avresti dovuto fare un po di test anche da remoto
 
Comunque che versione hai apache e kernel ?
 
Che distro  e che versione usi ?
 

 Che distro  e che versione usi ?
 
 
# cat /etc/redhat-release 
CentOS release 5.10 (Final)
 
# uname -a
Linux xxxxx 2.6.18-238.19.1.el5 #1 SMP Fri Jul 15 07:31:24 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
 
# httpd -v
Server version: Apache/2.2.21 (Unix)
Server built:   Sep 18 2011 01:32:00
 
 
il problema ha iniziato a presentarsi oggi, senza motivazione apparente.


Forse te ne sei accorto oggi, non che prima non ci fosse a parte 
aggiornamenti del kernel o di apache
 
La direttiva MaxClient che dice ?
Se è > 1000 riducila a non piu di 250 e ritenta
 
 
 
 

 Se è > 1000 riducila a non piu di 250 e ritenta
 
Circa 500, se la riduco a 250 taglio fuori metà del traffico.
Ma non è li il problema (ci ho già messo mano ed ha sempre funzionato per 3 anni di fila) ma poi sforare il maxclient logga un messaggio in error.log

 saprei causato da chi.
 
Io credo che sia un problema sulla coda dell'accept().
 
Ad ogni buon conto "tcpdump -n -i lo port 80" può darti una idea di quello 
che succede.
 
Analizza un dump di quando accade il problema e di quando non accade.
 

 che succede.
 
Ecco, già fatto, ma sinceramente non saprei cosa cercare.
Mi dovresti aspettare un mancato ACK in caso di timeout, ma se così fosse, poi come risolvo?

 poi come risolvo?
 
Mi fa piacere che tu lo avessi già fatto.
 
A maggior ragione, indipercuiepertanto, se non sai cosa cercare ti invito ad 
incollare dei casi significativi.
 

 incollare dei casi significativi.
 
Appena riesco a riprodurre il problema.
Adesso è un po di giorni che, inspiegabilmente, funziona (tra l'altro il traffico è il doppio rispetto a settimana scorsa quindi non penso sia un problema di carenza di risorse)

 problema di carenza di risorse)
 
Secondo me invece era proprio carenza di risorse.
Ma per approfondire ed eliminare eventualmente una delle due opzioni servono 
quei dump.