Re: Listen queue overflow

irq level, /server-status, socket?

Fai così: fai andare ogni minuto uno scriptino che ti salva lo stato della
macchina (comprese statistiche di apache24), socket, sysctl etc etc così
puoi fare una analisi a posteriori.
600 MaxClients mi sembrano tanti: quanta RAM hai? Quanta te ne occupa un
singolo processo httpd?


Il giorno 04 agosto 2014 20:28, Andrej Sossi <[email protected]> ha
scritto:

> 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
>



-- 
d.

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