[FoLUG] R: R: R: Server debian laptop

SkyborgSin skyborgsin@gmail.com
Gio 22 Gen 2009 20:49:44 CET


(stò cercando di recuperare i nomi e qualche riferimento, pazientate ancora
un giorno, ma intanto...)
Il debugging(ovvero come si crea un problema tentando di risolverne un
altro):
Datosi che il server in questione non è proprio performantissimo(diciamo che
siamo un paio di gradini sopra al pallottoliere con due barattoli e un filo
in mezzo) stasera mi sono messo a ravanare per tentare di spremere lo
spremibile.


   - acpid e kacpid non servono(comandi acpi non standard con la scheda, da
   aggiungersi ad eventuali problemi del contatto), quindi un bel killall
   all'avvio e risparmiamo qualche kb.
   - per l'uso che ne faccio del forum e compagnia bella, il bazilione di
   processi aperti da apache sono pure troppi(saranno una ventina di utenti
   quelli che ne usufruiscono, e solo un paio di ore al dì, quindi imposto i
   parametri *StartServers* , *MaxSpareServers* e *MaxRequestsPerChild* in
   modo da avere un solo processo in attesa finchè non arriva qualcuno, e di
   terminare i processi figli una volta trascorso un certo lasso di tempo(in
   modo da limitare il consumo massimo di ram)
   - fine tuning di mysql, un pò di caching su file non fà poi male a
   nessuno
   - Spostare i permessi di getty a runlevel 3, un rapido init 3 seguito da
   init2 libera i 7 terminali dal piccolo ma inutile login(tanto ai primi
   problemi di acpi si piantava anche la tastiera, quindi era semplicemente uno
   spreco)


Facendo ciò ho liberato un paio di mega addizionali(considerato che la
macchina ne ha 64 installati...) ma il dubbio rimaneva:
perchè cavolo anche nei periodi di inattività mi apparivano carichi da 0.86?
Dopo aver monitorato un pò la cosa con top scopro che la fetenzia era lo
scriptino di status che genera la famosa pagina (
skyborgsin.ath.cx/status.html) che altro non fà che cattare un pò di log(o
meglio, taccare, in quanto mi servivano i più recenti in alto), grep con la
data odierna meno un paio di condizioni variabili, sed i modo da sostituire
gli a capo con <br> e schiaffa tutto in /var/www.
La cosa pareva abbastanza facile, no?
E allora come mai un semplicissimo scriptino occupa da solo 15 mega di ram e
il 42% di processore?
E perchè impiega quaranta secondi per completarsi?
E perchè le query di mysql vanno in timeout appena lanciate durante questi
quaranta secondi?


Alla fine ho scoperto l'arcano: in fase di debug iniziale avevo inserito il
"logging del file di log", in pratica era un

cat status.html /root/back/logvecchio | sed 's/\<br>/\
/g' > /root/back/lognuovo
mv /root/back/lognuovo /root/back/logvecchio
rm status.html

All'inizio della procedura di status(che viene lanciata ogni 5 minuti,
ricordo).
Alla fine ho trovato la soluzione temporanea, ma mi ero dimenticato di tale
"log" (che nelle intenzioni iniziali doveva darmi le indicazioni dello
status di sistema appena prima di crashare) che era cresciuto a dismisura...
1 giga e rotti di log.
Inutile dire che il rallentamento era dovuto dallo sforzo di cattare e
spostare tale file, tolto quello improvvisamente mi trovo con load tra 0,01
e 0,6 con tre utenti loggati sul forum e due in ssh.

Ora, dove ho messo la carta per le decalcomanie, merita di avere la scritta
"Da grande sarò un Sun Blade" stampigliata sopra...

Il giorno 20 gennaio 2009 11.51, Enrico Placci <e.placci@gmail.com> ha
scritto:

>
> On 20/gen/09, at 11:24, Riccardo Corrado wrote:
>
>  Per quel che mi riguarda posta pure, sicuramente e' interessante!
>>
>
> +1
>
> Enrico
>
>
> _______________________________________________
> FoLUG mailing list
> FoLUG@lists.linux.it
> http://lists.linux.it/listinfo/folug per cancellarsi dalla lista
>


Maggiori informazioni sulla lista FoLUG