Newsgroup: it.comp.os.linux.sys
Titolo: Lentezza server [2]

Anche adesso è abbastanza lentino (mai quanto l'altro giorno).
Aggiungo che 2 settimane fa mi sono ritrovato nel syslog vari messaggi
VM: killing process httpd
VM: killing process pickup
VM: killing process proftpd
che in pratica mi han costretto al reboot del server.
Ecco alcuni dati:
top:
top - 12:06:49 up 9 days, 40 min,  1 user,  load average: 5.97, 4.47, 4.48
Tasks: 201 total,   1 running, 199 sleeping,   1 stopped,   0 zombie
Cpu(s):   4.2% user,   2.6% system,   0.2% nice,  92.9% idle
Mem:   1033212k total,  1001132k used,    32080k free,     5640k buffers
Swap:  1951800k total,   170376k used,  1781424k free,   133888k cached
(170mb di swap mi sembrano tanti, considerato il fatto che ho 1gb di ram)
C'è rsync in esecuzione (non avevo dubbi)
17044 root      18   0 80152  77m 1388 R 12.9  7.7  40:05.95 rsync
dmesg è tranquillo, nulla di strano
smartctl non dice nulla di strano.
rsync sta copiando xferlog di proftpd
I dischi stanno morendo
/dev/hda:
  Timing cached reads:   1644 MB in  2.00 seconds = 822.00 MB/sec
  Timing buffered disk reads:   24 MB in  3.44 seconds =   6.98 MB/sec
/dev/hdb:
  Timing cached reads:   1468 MB in  2.00 seconds = 734.00 MB/sec
  Timing buffered disk reads:   36 MB in  3.39 seconds =  10.62 MB/sec
Credo che quindi il problema stia proprio nel 2 dischi in raid sullo 
stesso canale (e quando parte rsync distrugge il server)

 stesso canale (e quando parte rsync distrugge il server)
E` probabile. Magari dipende anche dal fatto che usano lo stesso irq, e
che magari e` lo stesso anche della scheda di rete, e il gestore di irq
(hardware) non smista abbastanza velocemente, lasciando i processi
"appesi" a una open() o a una read().
Magari (se hai occasione di avere la macchina sottomano) potresti
provare con un kernel 2.6 (se non ho letto male hai il 2.4), che
gestisce la concorrenza (sia thread che processi) meglio.
Bye.
-- 
Alessandro Pellizzari

 E` probabile. Magari dipende anche dal fatto che usano lo stesso irq, e
I dischi sono una concausa.
MA il load a 150 (thread precedente) dimostra che c'è qualcos'altro che
stracarica la macchina.
Rsync non può generare, da solo, un load a 150.
Quindi, secondo me, hai altri problemi, oltre al disco, che ti saturano la
memoria.
MAx

 gestisce la concorrenza (sia thread che processi) meglio.
Si è 2.4 e adesso farò il porting a 2.6 (magari con patch 
ck).......tempo a disposizione permettendo.

 memoria.
Esattamente. E non saprei cosa.
Appena ho tempo metto su un 2.6 magari con patch ck e installo quelle 
applicazioni che mi hai consigliato stamattina in modo da fare un po di 
debug prima dopo e durante il blocco.

 ...[cut]...
l'hw naturalmente e' stato controllato vero (memoria e flat in particolare)?
-- 
Pandozy vede tutto
    _     _
  o' |,=./ `o
     (o o)    
 ooO--(_)--Ooo-

CtRiX ha scritto:

Il carico alto lo puoi avere anche con un grosso sovraccarico in zona 
dischi; dovrebbe controllare che i/o wait ha quando ha il piantone.
A me il carico è sceso da 40 a circa 10 abilitando il writeback sul 
controller scsi
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Preferirei essere negro piuttosto che gay, perche' se sei negro non lo devi
dire a tua madre!
		-- Charles Pierce

 
Mi pare che non ci sia il valore di i/o wait nel 2.4........
Il porting a 2.6 si rende sempre piu indispensabile........

 controller scsi
Non ho dubbi. Il disco è una concausa.
il tuo 40 sono processi (presumo) di postfix.
Ma i suoi 150 cosa diavolo sono ?
e tutti che girano contemporaneamente.
A me sa tanto di phpbb o di mambo con un db scritto e indicizzato male
durante un periodo in cui tutti si divertono a sclicchettare...
MAx

 Non ho dubbi. Il disco č una concausa.
Dimenticavo.
E' una concausa anche la mancanza di memoria.
Se hai 500 mega di swap piena fa piů danni quella di un disco lento.
Max

 durante un periodo in cui tutti si divertono a sclicchettare...
Anche a me sa tanto di un php fatto da cane....
Il db credo non sia un problema in quanto č su una macchina dedicata.
A meno che il php sia fatto talmente male da fare un query distruttrice 
al db e bloccare il server web finche non termina la query.
Esiste un modo/script_pre_confezionato per vedere quale sito sta 
demolendo il server?

 Se hai 500 mega di swap piena fa più danni quella di un disco lento.
Immagino che la swap rallenti moltissimo il sistema quindi.
Vado al supermercato a prendere la ram.

 demolendo il server?
Non in maniera chiara ed efficace, se tutti i siti girano con lo stesso
utente.
Puoi abilitare il logging di myslq (occhio che sotto carico ammazza la
macchina) per vedere quali query e quali connect ricevi.
Puoi configurare il php come fastcgi con suexec, in modo che ogni sito giri
con il suo utente dedicato e allora con TOP pui vedere quali processi (e a
chi appartengono) utilizzano o uccidono la macchina.
MAx

 chi appartengono) utilizzano o uccidono la macchina.
Problemi di sicurezza? Tu come lo usi? con fastcgi?
Io ho sempre usato il php come modulo di apache......la soluzione cgi 
non mi sembra molto 'sicura'.

 non mi sembra molto 'sicura'.
suexec= lento ma sicuro.
fastcgi (wrappato con suexec) = sicuro e veloce quanto il modulo.
Ogni sito ha il proprio userid e il php gira con quello => molta più
sicurezza e granularità nelle configurazioni e nei permessi.
Tralascio di dire che è un dito al culo configurarlo bene /magari con gli
utenti su DB e non di sistema).
Io lo uso come suexec+fastcgi su alcune macchine, come modulo su altre, in
funzione di cosa ci deve girare sopra.
MAx

 funzione di cosa ci deve girare sopra.
Dove trovo un howto? :)

 
Come hai ottenuto questi dati??????

 
Qui:
it.comp.os.linux.iniziare

 Dove trovo un howto? :)
Su google, a spizzichi e bocconi.
Io ci ho bestemmiato non poco.
Però funziona da dio.
Max

 e tutti che girano contemporaneamente.
Potrebbero essere benissimo dei processi parzialmente swappati che
devono girare, ma che sono starved da rsync.
Se fosse il 2.6 si potrebbe fare nell'ordine:
- abbassare la swappiness: /proc/sys/vm/swappiness (c'e` anche nel 2.4?)
- usare lo io-scheduler cfq
- lanciare rsync con un nice alto, in modo che la classe assegnata da
  cfq sia ristretta
Luca
-- 
Home: 
http://kronoz.cjb.net
"It is more complicated than you think"
                -- The Eighth Networking Truth from RFC 1925

 Che problemi può dare a livello di consumo di risorse rsync???
E` fondamentalmente io-bounded (dal disco ovviamente); il problema e`
che con tuning errati della VM la page cache potrebbe crescere in modo
abnorme mandando il thrashing il sistema.
Luca
-- 
Home: 
http://kronoz.cjb.net
Sbagliare è umano, ma per incasinare davvero le cose serve un computer.