glug: configurazione apache+php (risposta molto lunga...)

[Ivan Porro]

ciao

scusate il reply tecnico, soprattutto se tecnico non e' ma sono boiate.... non 
so se sia da lista o meno, sicuramente OT rispetto a quello che serve a Takke 
al momento ;-) pero' ho un po' di confusione in testa...credo si possa capire 
da quanto segue...

Prendendo come spunto il tema "Apache thread", dando un piccolo carico al 
server, 4 wget ricorsivi contemporanti, in un Apache2 con modello di thread 
prefork, capita che, una volta finito il carico, risultano appesi quasi tutti 
i thread creati dall'inizio del test, sia di apache che di mysql (anche se 
tutti in "S"leeping). Mettiamo che quelli di mysql possano essere errori nel 
codice, tipo connessioni che restano appese, ma quelli di Apache?  E quel 
mattone di Zope -> 6 processi python da 53mega l'uno (anche se 6 sono in 
shared...)? 

La cosa non va molto d'accordo con il load average: 0.03, 0.08, 0.21  (in 
ordine come da top: 1,5,15 minuti fa)

Quindi, o non mi e' chiaro cosa da in output il comando top (ipotesi 1: 
memoria del processo, totale, indipendentemente dal numero di thread in cui 
si divide), ipotesi avvalorata dal fatto che l' RSS e' identico per tutti i 
thread mostrati ( comando H da dentro il top per vedere/nascondere i thread)

oppure (ipotesi2) questa mail diventa un RTFM da far paura, nel qual caso, 
amen, me lo becco, e seguo le indicazioni :)

grazie in anticipo

	ivan


 

Alle Tuesday 25 January 2005 17:46, Marco Masetti ha scritto:
> Ok, la risposta e' stata gia' data dal Debe, ed adesso che il php respira
> ritorniamo sui nostri passi e cerchiamo di capire qualcosa...
>
> > Hai verificato se apache carica php4_module?
>
> un modulo puo' essere staticamente compilato con apache (e quindi sara'
> gia' presente in ogni processo httpd) oppure puo' essere caricato
> dinamicamente allo start up del processo principale. Il vantaggio di
> caricare un modulo dinamicamente al runtime e' che verra' condiviso da piu'
> processi e quindi risparmieremo parecchia ram durante l'esecuzione, guarda
> questo estratto del comando top:
>
>  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>  9479 root      15   0  2912 2028  1976 S     0.0  0.3   0:00 httpd
>  9499 webAppal  15   0  4168 3776  3060 S     0.5  0.7   0:04 httpd
>
> che ci dice che ogni processo httpd figlio (quelli per interdeci che
> servono le richieste http) occupa circa 3.7 Mb in RAM (colonna RSS), ma di
> cui ben 3 Mb sono moduli shared (colonna SHARE), e questo ci permette di
> farne girare un bel po' (o almeno di dire non e' certo per colpa di apache
> che siamo a corto di Ram...). I moduli condivisi hanno estensione '.so'.
>
> [come capire se un module e' presente nel processo]
> Per verificare se un modulo e' compilato staticamente nel binario basta
> rintracciare il binario httpd ed eseguire il comando:
>
> #>./httpd -l
>
> che ci da la lista dei moduli compilati nel processo.
> A questo punto si presentano tre casi:
>
> 1) massimo culo
> nella lista compare il fatidico mod_php4
>
> 2) culo normale
> nella lista non compare il fatidico mod_php4 ma ci si apre il cuore
> trovando invece il modulo mod_so, chi non sa a cosa serve legga oltre...
>
> 3) massima sfiga
> entrambi i moduli non rispondono all'appello.
>
> [a cosa serve mod_so]
> Serve a permettere ad apache di lincare dinamicamente librerie a runtime.
>
> [come compilare apache con il supporto per i shared objects]
> Se ci capita di ricompilare Apache (e dovremo per forza farlo se rientriamo
> nel caso 3), per essere sicuri di trovarcelo dentro bisogna dare il comando
> (una volta scompattato il tarball con i sorgenti)
>
> #> ./configure --enable-module=so [ + altri parametri di configurazione]
>
> [come si compila un modulo come shared per apache]
> Con apache2 di solito basta fargli capire dove e' il tool apxs (Apache
> extension tool, si trova tra i binari di apache). Se la libreria si compila
> con la solita sequenza di solito bastano i comandi:
>
> #> ./configure --with-apxs=<path to apxs> [+ altri parametri]
> #> make && make test && make install
>
> una volta ottenuto il modulo <qualcosa>.so, possiamo tranquillamente
> spostarlo a mano sotto il direttorio $APACHE_HOME/modules se abbiamo apache
> 2 (o $APACHE_HOME/libexec per apache 1.3)
>
> [come si configura il caricamento di un modulo]
> Il Debe ha mostrato le direttive per il purista, colui che ha raggiunto il
> mantra.
>
> > In caso negativo devi abilitare il modulo e far ricaricare ad apache la
> > nuova configurazione.
> >
> > Traduzione:
> >
> > if [ -z $(apache-modconf apache query mod_php4) ]
> >   then
> >     apache-modconf apache enable mod_php4
> >     /etc/init.d/apache reload
> > fi
>
> in realta' un semplice:
>
> LoadModule php4_module        modules/mod_php4.so
>
> piazzato da qualche parte nell'httpd.conf dovrebbe bastare (ed e' inoltre
> la soluzione standard, che va bene su qualunque piattaforma....)
>
> Ciao,
> Marco.
> PS: l'avevo detto che era lunga! Non ti arrabbiare se ti ho fatto perdere
> 10 minuti del tuo tempo!
>
> > --
> > ciao,
> > debe
> > _______________________________________________
> > glug mailing list
> > glug@genova.linux.it
> > http://lists.linux.it/listinfo/glug