Newsgroup: it.comp.os.linux.sys
Titolo: restartare un apache sotto carico decente

Ciao, ieri sera uno dei miei siti ha avuto un problema con apache.
credo si tratti di un segfault di qualche tipo, praticamente i processi 
erano attivi ma lui non rispondeva più. i backend mysql erano in ordine 
quindi il collo di bottiglia è diventato lui.
secondo voi schedulare un restart di apache ogni 30 minuti è una buona idea?
considerando che i primi secondi per lui sono sempre un po' traumatici.
apache lavora dietro a un server lighttpd che funge da transparent proxy, 
questo per far sì che molti ip non aprano molti thread ma apache veda sempre 
un unico IP. insomma mi hanno spiegato così grossomodo e effettivamente ha 
migliorato molto le prestazioni.
altra domanda, è possibile da nagios (che è installato su un altro server) 
in caso di crash http faccia uno stop / start su un altro server?
-- 
give it away

 server?
Se Apache non risponde più, il controllo lo puoi fare anche dalla 
macchina locale in maniera molto più semplice e senza nagios.
In sostanza, stai sbagliando approccio:
- prima si capisce dove è il problema 
- dopo si risolve lo specifico problema.

 migliorato molto le prestazioni.
Huh? E da quando avere tutte le connessioni da un unico ip migliora le
prestazioni?
Cerca di capire cosa succede e perche' invece.
Davide

 Cerca di capire cosa succede e perche' invece.
non succede spesso che apache si incanti comunque i messaggi che ho trovato 
nei log sono grossomodo questi: 
da dmesg:
apache2[21505]: segfault at 00007ffff4746918 rip 00002b6cb9d52fc7 rsp 
00007ffff4746920 error 6
apache2[22324]: segfault at 00007ffff4746e38 rip 00002b6cb9d52fc7 rsp 
00007ffff4746e40 error 6
apache2[20674]: segfault at 00007ffff4745408 rip 00002b6cb9d52fc7 rsp 
00007ffff4745410 error 6
da error_log:
[Fri Oct 16 17:46:51 2009] [notice] child pid 17819 exit signal Segmentation 
fault (11)
[Fri Oct 16 17:46:51 2009] [notice] child pid 23809 exit signal Segmentation 
fault (11)
[Fri Oct 16 17:46:53 2009] [notice] child pid 17952 exit signal Segmentation 
fault (11)
ora cerco di capire cosa diamine vuol dire tutta sta roba...
che strumenti ho per capire questa miriade di errori?
-- 
give it away


Quando ero giovane e incosciente mi dicevano che un sig11 era spesso indice 
di ram bacata
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
www.robyt.eu

 indice di ram bacata
azz, ovviamente dire che è un server parecchio costoso ed è tutta ram ECC 
vale poco vero?
 
-- 
give it away

majale wrote:

secondo me è qualche porcata che ho fatto io nel codice php.
me lo sento...
-- 
give it away

majale ha scritto:

Ci sono stati, negli anni, svariati problemi con il php, e alcuni
si evidenziavano proprio con dei sani segfault.
Come stai, a versioni?
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 sento...
Porcate scritte in PHP non possono generare sig11.
Puo` essere un modulo di php buggato o compilato con una libreria 
sbagliata. Per esempio per un pezzo anche in Debian stable (mi pare woody) 
e` rimasto un modulo che crashava apache appena si caricava, e suphp ha il 
brutto vizio, se trovava i permessi sbagliati nei file, di ammazzare il 
processo PHP lasciando solo un criptico "headers truncated" (o simile) nei 
log.
Bye.

 Come stai, a versioni?
PHP Version 5.2.6-0.dotdeb.1
apache è alla versione 2 ma ora non riesco a capire che versione sia 
precisamente API version dice 20051115
facendo ServerSignature On in httpd.conf non riesco comunque a vedere la 
versione precisa.
-- 
give it away

majale wrote:

ii  apache2                           2.2.3-4+etch4                            
ii  apache2-mpm-prefork               2.2.3-4+etch4                            
ii  apache2-threaded-dev              2.2.3-4+etch4                            
ii  apache2-utils                     2.2.3-4+etch4                            
ii  apache2.2-common                  2.2.3-4+etch4                            
eccolo
-- 
give it away

 
credo di aver trovato il problema: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=46467
ora non ho idea di come proseguire però.
-- 
give it away

 sento...
Gli ultimi PHP talvolta lo fanno.
Con il modulo mysql, con il modulo curl quando è caricato prima di quello 
di postgres ed altre cosine carine...

CtRiX wrote:

il sito usa:
memcached e anche mysql. leggevo in giro che pare essere proprio il modulo 
memcached il colpevole.
ora cerco di ottenere più informazioni, perché non è bello se muore un pid 
al secondo...
-- 
give it away

 fault (11)
Questo e' in genere una indicazione di un qualche modulo che si
incarta o che va' in conflitto con un altro modulo.
Davide

 e' quello che fanno).
Si vabbè la spiegazione in inglese è arzigogolata non poco.
Il succo è che davanti c'è un proxy che poù aiutare.
Che poi non sia la soluzione migliore possiamo discuterne.
Max

 Che poi non sia la soluzione migliore possiamo discuterne.
se avete un server con alto carico su apache fate un test, vi renderete 
conto di quanto migliora la situazione.

 conto di quanto migliora la situazione.
Di solito prima di aggiungere un proxy, si ottimizza il codice e le query.
In secondo luogo, prima di aggiungere un proxy, preferisco aggiungere 
un'altra macchina per bilanciare il carico sui due server e per dormire 
più tranquillo.
I proxy nel 95% dei casi danno più problemi che altro, a mio 
personalissimo avviso.

 personalissimo avviso.
Il mio fido pound non mi ha mai dato un rogna che sia una, ti dirò.

 personalissimo avviso.
è trasparente il proxy, ho spiegato sopra il perché



Se il proxy è trasparente in senso stretto (non cacha) non serve ad una 
mazza.

 (ed e' quello che fanno).
Dipende da quante connessioni gli dici che deve servire un processo prima 
che lo uccida. In ogni caso è generalmente vero che mettere un proxy davanti 
ad Apache gli fa solo bene (e che Apache è una bestia lenta come tutto e che 
se si può evitare è meglio - dicasi lighttpd, dicasi nginx ecc)
-- 
Vide

CtRiX wrote:

ma hai letto la spiegazione che ha dato il tizio e ho trascritto?
ti posso assicurare che senza quel proxy in lighttpd avrei bisogno di altri 
2 server http.
-- 
give it away

 2 server http.
Guarda, è matematico.
Se ti arrivano 1000 richieste al secondo (come esempio) e se usi un 
transparent proxy che quindi non fa caching, ti arriverebbero 1000 
richieste al secondo anche su apache.
Su questo credo che ci possa essere poco da dire.
Premesso questo, se il carico si abbassa su apache, l'unica ipotesi che 
posso fare è che il tuo proxy serializzi le richieste, ovvero ne metta 
una dietro l'altra. Ma sempre 1000 al secondo sono. 
Solo che serializzandole, vengono accodate e quindi, mediamente, hai la 
controindicazione che ogni richiesta ci mette più tempo.
Non vedo come N richieste in entrata che diventano N su apache possano 
altrimenti diminuire il traffico. E' matematico.
Altrimenti non fa solo da transparent proxy ma fa anche altro.

 altrimenti diminuire il traffico. E' matematico.
forse, e dico forse, lighttpd parla http/1.1 verso apache e quindi 
utilizza la stessa connessione tcp per fare richieste diverse.
forse...
bye
-- 
Mi contraddico, forse?
Ebbene mi contraddico (sono vasto, contengo moltitudini)
                                         -- Walt Whitman

 altrimenti diminuire il traffico. E' matematico.
let me explain - if client's connection is not very fast, then apache child 
will be running until it transfers all data to client. and because of it 
you have a lot of apache childs running.
and if there is lighttpd running as proxy - then it will get data from 
apache, and apache child will be closed. after that lighttpd will send data 
to client
-- 
give it away

 will be closed. after that lighttpd will send data to client
OK, ma cosi` raddoppi i processi, perche` hai quelli di apache e quelli di 
lighttpd...
A quel punto conviene mettere direttamente lighttpd, da solo o magari a 
servire le parti statiche e girare ad apache solo quelle dinamiche, oppure 
avere due server apache (se hai light su un secondo server) a servire in 
round robin tramite dns.
Bye.

 round robin tramite dns.
questo è quello che viene fatto per i due server http che mandano i binari 
attraverso pfsense. ma sono proprio un altro dominio
-- 
give it away

 round robin tramite dns.
il problema è che per linguaggi come il PHP la soluzione che da meno 
problemi/più performante continua ad essere apache + mod_php. Anche se 
ammetto di no naver mai provato FastCGI con PHP (stessa infrastruttura) per 
fare confronti diretti.
-- 
Vide

 CPU/RAM
Nemmeno quelli di apache, quando configurato a dovere.

CtRiX wrote:

vabbhe, non hai idea di cosa deve fare il sito in questione quindi è inutile 
continuare il discorso.
ciao!
-- 
give it away

 inutile continuare il discorso.
No, sei tu che stai parlando a vanvera.
Vedasi inizio del thread in cui non sapevi nemmeno perchè ci avevi messo 
un lighthttp (perchè apache vede sempre un solo ip eh!).
Quando confronti apache e lighthttp, i paragoni si fanno a parità di 
funzionalità.
Apache (2.X) configurato a dovere come proxy non è inferiore di molto a 
lighthttp.
Semplicemente, la tua conoscenza e la tua esperienza è da utente (o da 
programmatore web) e non da sistemista. Per questo non capisci.

 programmatore web) e non da sistemista. Per questo non capisci.
sicuro, sennò non avrei chiesto consulenza a un guru che analizzata la 
situazione ha deciso di piazzare lighttpd davanti ad apache e ha ridotto il 
carico del server in maniera eccezionale.
puoi configurarlo bene quanto vuoi apache, ma se ti servono dei moduli e 
deve fare qualcosa in più che fornire contenuti statici fidati che ha dei 
problemi nello scalare quando hai più di 4000 utenti collegati 
contemporaneamente. 
se hai un sito a disposizione con un traffico decente fai una prova (se ti 
servono i file di configurazione te li passo volentieri), così vedrai che 
aumenterai le tue consocenze in merito.
-- 
give it away

 che aumenterai le tue consocenze in merito.
Fai poco lo sborone che con me caschi male in merito ai server web !

 Fai poco lo sborone che con me caschi male in merito ai server web !
sono contento se sei così in gamba c'è sempre bisogno di gente preparata! 
dovresti valutare però che c'è sempre qualcosa che non si conosceva poco fa 
e c'è inerzia mentale nel cancellare i dogmi personali.
la mia era una proposta di genuina curiosità, fai un test se ti capita e 
fammi sapere come ti ci trovi. magari recuperi un po' in simpatia oltre che 
in risorse del server.
http://adil.az/web-server/lighttpd-frontend-apache-backend/
http://blogs.walkerart.org/newmedia/2008/11/22/installing-a-lighttpd-proxy/
http://www.mysqlperformanceblog.com/2006/11/12/are-php-persistent-
connections-evil/
poi se preferisci rimanere nel tuo perché nei libri sacri c'è scritto che 
apache è sempre perfetto casomai sono i programmatori a fare minchiate per 
me va bene, grazie al cielo non sei mio consulente

 83 requests currently being processed, 0 idle workers
Che macchina hai per gestire 251 req/sec con 83 worker?

Gandalf Corvotempesta wrote:

ora che c'è un po' più di traffico è così:
Server uptime: 1 hour 53 minutes 2 seconds
Total accesses: 2181781 - Total Traffic: 7.3 GB
CPU Usage: u712.45 s141.37 cu68.67 cs0 - 13.6% CPU load
322 requests/sec - 1.1 MB/second - 3606 B/request
56 requests currently being processed, 13 idle workers
_...___WK_.KWWWWCKWW.KKK._.WWWK.W_WWWW._KW.WWKK_..WK.KKCW.K.....
W....K.W..R..._K....W.....KW...WW.K_....K..W....W...............
..........................W.....K......_...._.W.................
..........K................W....W...............................
................................................................
................................................................
................................................................
................................................................
................................................................
........................
comunque è un Dell Intel(R) Xeon(R) CPU E5...@2.50GHz 4 cpu fisiche.
con 8 giga di ram e dischi a 15k su debian.
e si occupa solamente di fare il servizio http per il sistema che ho scritto 
in php, fa anche servizio smtp locale per la gente che si iscrive etc ma 
quello ha carico pressoché ininfluente. 
dietro ha 4 server più o meno identici che forniscono i dati su un sistema 
mysql MMM (master master mysql) in cui ci sono 2 master e 2 slave.
più altri 2 server http per i contenuti statici.

 con 8 giga di ram e dischi a 15k su debian.
4 core, vorrai dire.
O un quadriprocessore?
Non riesco a credere (ed infatti non ci credo) che un eventuale
quadriprocessore, visto che parli di cpu fisiche, non riesca
a reggere un carico di 322/req/sec e 8mbit/s.
Prova a togliere il keepalive.
Nelle mie installazioni ho sempre notato che il keepalive porta
solo ad un risultato: rompere i coglioni.

 solo ad un risultato: rompere i coglioni.
proverò, ti farò sapere se migliora, è sempre meglio avere una macchina in 
ordine. ciao

 ordine. ciao
al momento comunque ho 
KeepAliveTimeout 2
che è piuttosto basso.

 che è piuttosto basso.
Si ma ho frainteso, son stanco anche io.
Avevo capito che non ti reggeva il carico dai tuoi
ultimi messaggi.... Se non hai problemi di load,
lascia stare il keepalive.

 ora non ho idea di come proseguire però.
Il workaround segnalato nel commento 8 non va bene ?
Cioa. 
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 
non lo so, purtroppo il mio kernel non crea 
/proc/sys/fs/epoll/max_user_instances

 minchiate per me va bene, grazie al cielo non sei mio consulente
Non sto dicendo questo.
Sto dicendo che nel 100% dei casi, apache non è il server più veloce per 
servire contenuti statici. Ma il limite è BEL OLTRE le 250 richieste al 
secondo (aumenta pure di un ordine di grandezza almeno).
Nel 99,999% dei casi, quando apache è lento, il problema non è apache ma 
è il "content generator" ovvero php, perl o quello che vuoi ed è li il 
problema.
Tutto quello che hai scritto dimostra che tu stesso non hai capito di 
cosa si parla, dell'approccio al TUO problema e delle soluzioni.
Giusto per aggiungere qualche dettaglio, copio ed incollo dal tuo secondo 
link:
"The approach was two-fold: *some quick auditing and re-writing of the 
worst offending .wac pages’ SQL to speed up the slow pages*, and yet 
another web server in front of everything"
"Between the SQL tuning and the extra resources, the bulk of these pages 
are now served between 2 and 10(!!!) times faster!"
Chiaro no ?

ciao, riapro questo thread perché purtroppo stanotte alle due il sito è di 
nuovo crashato..
so che sarebbe semplice fare uno script per restartare apache in caso non 
sia attivo, ma quel che succede qui è che i processi apache sono ancora 
attivi, solo che non sono in grado di servire nulla.
mi servirebbe un aiuto su uno script in grado di capire se la porta 80 è in 
grado di fornire contenuti e in caso contrario restartare apache.
idee?
-- 
give it away