Re: Listen queue overflow

On 04. 08. 2014 18:11, Davide D'Amico wrote:
 > Nessun messaggio di errore relativo al MaxClient raggiunto o hai 
controllato quanti processi httpd hai nel momento in cui appare quel 
messaggio?
 > Che worker stai usando su apache24? Te lo fa anche con apache22?

Estratto del file /usr/local/etc/apache24/extra/httpd-mpm.conf
<IfModule mpm_prefork_module>
     StartServers             5
     MinSpareServers          5
#    MaxSpareServers         10
     MaxSpareServers         20
     MaxClients             600
     ServerLimit            600
     MaxRequestWorkers      250
     MaxConnectionsPerChild   0
</IfModule>

Ho già cercato di aumentare, ma senza successo. Nei log di apache non 
trovo nulla al riguardo. Ho solo un:
[mpm_prefork:warn] [pid 1415] AH00179: changing ServerLimit to 600 from 
original value of 256 not allowed during restart

Come conseguenza dell'aumento dei parametri sopra.

On 04. 08. 2014 18:35, Andrea Brancatelli wrote:
 > Ciao Andrej
 >
 > anche io ho lo stesso problema su un server di posta che riceve 
numerose connessioni IMAP in ingresso.
 >
 > Dalle mie indagini dipende dal fatto che in pratica non c’è “nessuno” 
che si faccia carico della connessione TCP entrante in tempo utile. In 
pratica la porta è in Listen ma poi il sistema operativo non riesce ad 
agganciarci un processo in un tempo ragionevole.
 >
 > Sinceramente io non ho trovato particolari soluzioni, quindi se trovi 
qualcosa fammi sapere :-)
 >
 > Comunque non penso sia un problema di configurazione di Apache. Al 
massimo bisognerebbe trovare il parametro di sysctl relativo alle 
connessioni entranti, o alle dimensioni del buffer delle stesse.
 >
 > Tra l’altro penso che essendo un errore al livello TCP l’utente non 
si accorga neanche di niente di particolare, e sia il protocollo stesso 
a riprovare… no?

Sono d'accordo con le tue conclusioni o più correttamente è più o meno 
quello che sono riuscito a capire leggendo altre discussioni in merito. 
Quello che non riesco a capire è perché Il sistema Operativo non riesca 
a trovare un processo di (httpd nel mio caso) che elaborare la 
richiesta. Ho un altro server che è molto sotto stress a causa delle 
risorse limitate e quando le supera e comincia a scaricare nella swap GB 
il server risulta non reattivo e le connessioni restano appese anche 
alcuni minuti prima che vengano effettivamente passate al processo. 
Quest'ultima macchina è un FreeBSD 8.2 quindi la comparazione forse non 
è così corretta.
In questo nuovo server ho risorse in abbondanza, quindi non dovrebbero 
esserci casi simili. Anzi vorrei sfruttare al massimo le risorse del 
server, ma dopo varie prove non sono riuscito a trovare dove dover agire.

@Davide D'Amico
Ripeto nuovamente, il server è un server web e-commerce. Mediamente non 
ho un carico enorme, ma succede sporadicamente che ho dei picchi di 
richieste. Alcune pagine prima di caricarsi possono impiegare fino a 2 
secondi (caso di ricerca nel catalogo prodotti). Il problema è che 
essendo questi casi troppo sporadici non riesco a vedere cosa sta 
succedendo nel preciso istante dell'errore ne valutare la reale 
reattività del server. Mi accorgo tipicamente il giorno dopo quando mi 
arriva il messaggio 'daily security run output'.

 > Il giorno 04 agosto 2014 16:02, Andrej Sossi <[email protected]> ha 
scritto:
 >
 >     On 04. 08. 2014 16:30, Davide D'Amico wrote:
 >
 >         Mi sembra tutto corretto e per nulla 'sotto stress'; hai 
provato a dare un'occhiata a questo articolo: 
http://lawrencechen.net/2014/sonewconn-pcb-0xfffffe006acd9310-listen-queue?
 >
 >         d.
 >         [...]
 >
 >
 >     Il server al momento non è sotto stress. Sinceramente mi sono 
accorto della difficoltà solo dai log. Dato che è un server web subisce 
dei picchi di lavoro che non sono prevedibili a priori. In più posso 
dire che i messaggi spuntano numerosi solo una o due volte alla 
settimana o anche una volta ogni paio di settimane. Questo mi rende 
anche difficoltoso provare vari accorgimenti e configurazioni.
 >
 >     Già verificato anche il blog citato. Se ho ben capito ha mostrato 
tutto il procedimento che ha utilizzato per determinare quale processo 
era sotto stress. Nel mio caso il processo è sicuramente apache httpd, 
dato che è l'unico esposto pubblicamente. Nel blog però non scrive come 
aumentare la coda o come permettere ad httpd di aumentare le risorse in uso.
 >
 >     In un altro sito ho anche trovato il consiglio di modificare le 
connessione ipc:
 >     sysctl kern.ipc.somaxconn=256
 >     Anche questo non ha limitato la comparsa dei messaggi di log.
 >
 >
 >     --
 >     Cordiali saluti
 >     Sossi Andrej
 >     -------------------------
 >     DOTCOM Information technology
 >
 >     Via Trento, 16
 >     34132 - Trieste (TS)
 >     Italy
 >
 >     tel: +39 040 9828090
 >     fax: +39 040 0641954
 >     E-mail: [email protected]
 >     ----------------------------
 >
 >     Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si 
precisa che le informazioni contenute in questo messaggio sono riservate 
e ad uso esclusivo del destinatario. Qualora il messaggio in parola Le 
fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e 
di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie
 >
 >     This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may 
contain confidential and/or privileged information. If you are not the 
addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose or take any action based on this message or any 
information herein. If you have received this message in error, please 
advise the sender immediately by reply e-mail and delete this message. 
Thank you for your cooperation.
 >
 >
 >     _______________________________________________
 >     Esperti mailing list
 >     [email protected]
 >     http://mailman.gufi.org/mailman/listinfo/esperti
 >
 >
 >
 > --
 > d.
 > _______________________________________________
 > Esperti mailing list
 > [email protected]
 > http://mailman.gufi.org/mailman/listinfo/esperti

-- 
Cordiali saluti
Sossi Andrej
-------------------------
DOTCOM Information technology

Via Trento, 16
34132 - Trieste (TS)
Italy

tel: +39 040 9828090
fax: +39 040 0641954
E-mail: [email protected]
----------------------------

Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie

This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.



_______________________________________________
Esperti mailing list
[email protected]
http://mailman.gufi.org/mailman/listinfo/esperti