Newsgroup: it.comp.os.linux.sys
Titolo: Aumento di performance con ramdisk

Ciao a tutti,
in ufficio ho un sistema di reportistica che sta soffrendo e che non posso
carozzare meglio. Ha sempre la CPU al 100% di cui 85% user e 15% system.
L'attivita' del sistema e' solo reportistica basata su mrtg, quindi
sostanzialmente legge in continuazione n file di configurazione (circa 500
interrogazioni ogni 5 minuti per una media di 4 interfacce a device), fa le
sue belle query snmp, e scrive l'output sui classici file di testo. Mi sto
sempre piu' convincendo che il grosso del peso sia dovuto al continuo
accesso al disco.
La prima soluzione che ho pensato e di spostare mrtg su rrdtool abbandonando
i file di testo ma non so come valutare l'eventuale guadagno di performance.
La seconda è di spostare o i file di configurazione, o i file di output od
entrambi su un ramdisk (al momento l'occupazione dello spazio disco per le
statistiche e' di circa 995MB e considerando l'inevitabile crescita dovro'
comunque chiedere l'autorizzazione ad un aumento di ram). Questo dovrebbe
ridurre gli accessi al disco fisico e scaricarmi il sistema ma avrei il
problema dell'allineamento dei dati in modo che siano persistenti. Almeno
che non dica una stupidata, il ramdisk non mi garantisce la scrittura su
disco. Allora ho pensato che potrei fare un link soft della directory sul
disco fisico verso il ramdisk ipotizzando che il ramdisk verra' gestito come
un disco fisico e quindi il sistema effettuera' la sua bella cache per
effettuare il flush su disco nei momenti di idle del sistema. Ma e' vero? E
se si, guadagno in performance tanto da giustificare la spesa di un altro
giga di ram?
Grazie a chiunque sapra'/vorra' rispondere ai miei dubbi o abbia consigli da
darmi.
Ciao
 Nameci

 
[cut]
per darti qualche consiglio significativo, imho manca un dettaglio 
fondamentale: che dischi monta adesso il tuo sistema?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 giga di ram?
Se il collo di bottiglia sono gli accessi al disco, con il ramdisk
guadagni molto.
E comunque sai, 1GB di ram costa 20 euro, non credo sia una spesa da
'giustificare'
Eventualmetne, non puoi usare il ramdisk e fare una copia verso il
disco ogni 30 minuti, ad esempio? Giusto per evitare perdita di dati
in caso di crash del server...

 fondamentale: che dischi monta adesso il tuo sistema?
Non sono in ufficio e non posso verificare marca e modello comunque sono
dischi scsi da 500gb in raid1 hw da 10000rpm.
Ciao

 in caso di crash del server...
Si, era un'alternativa ma quasi un giga di dati ogni 30 minuti mentre il
sistema continua ad aggiornare i file delel statistiche temo che non mi
risolverebbe il problema.
Ma una cosa non mi è chiara. Il ramdisk è un file fisico su disco che il
sistema dovrebbe caricarsi in memoria quando lo si monta. Ma effettua delle
scritture su disco per rendere i dati consistenti ogni tanto o sono tutti
dati persi?

 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Receiving a million dollars tax free will make you feel better than
being flat broke and having a stomach ache.
		-- Dolph Sharp, "I'm O.K., You're Not So Hot"

 dati persi?
Se ti si spegne il PC, tutto quello che hai nel ramdisk va perso.

 dovuto al continuo accesso al disco.
Anche secondo me 1 GB di RAM in piu`, e magari la modifica del tempo di 
commit dei buffer su disco risolvono in modo semplice e veloce il problema.
Comunque se hai l'85% di user significa che per gran parte del tempo quel 
PC fa calcoli veri e propri, quindi anche la CPU e` quasi al limite.
Bye.

 
il ramdisk e' non e' un file, e' una parte di ram che viene utilizzata per 
simulare un disco.
quando il ramdisk e' inizializzato, lo usi come qualsiasi altro disco 
fisso; ci copi sopra files, cancelli, apri, modifichi.
solo che se togli corrente, perdi tutto il contenuto del ramdisk.


 in uso, ma si puo') e cercare di vedere se porta guadagni.
http://www.faqs.org/docs/perl5int/compiler.html
Da quella pagina:
"It's important to know what the Perl compiler is not. It's not
something which will magically make your code go faster"
quindi non vedo in che modo possa portare vantaggi.

 carozzare meglio. Ha sempre la CPU al 100% di cui 85% user e 15% system.
In quell'85% c'è la tua risposta, senza guardare oltre.
Il disco non c'entra.
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?


Lo so che l'attivita' e' pesante, ma non credo che sia preoccupante un
sistema che dedica allo user gran parte della CPU, altrimenti a che mi serve
il computer se non a sfruttarlo ;-). Invece sono piuttosto convinto che un
sistema che costantemente sia sopra il 3-4% in system sia un sintomo di
reale sofferenza.
Sbaglio?

 wrote in message
news:417f44da-35c4-498d...@c65g2000hsa.googlegroups.com...

Penso che intendesse, non tanto la velocitą, ma che compilando non viene
piu' interpretato e quindi dovrebbe ridurre l'uso di cpu che ha un compito
in meno

 Sbaglio?
E` una sofferenza del 15% contro una del 85%...
Se vuoi dimunire il dolore, dove hai le migliori possibilita`?
Detto cio`, non mi e` chiaro quale sia il tuo obbiettivo?
E` un problema che la macchina sia al 100%?
Se il sys time fosse zero, sarebbe lo stesso al 100%,
oppure scenderebbe all'85%?
Fa quello che deve fare in tempo utile oppure sfora?
bye,
-- 
piergiorgio

 solo che se togli corrente, perdi tutto il contenuto del ramdisk.
Ok, quindi io potrei crearmi il ramdisk, montarlo, copiarci gli script
riducendo almeno in parte gli accessi al disco fisico. Quando modifico gli
script devo solo avere l'accortezza di copiarli anche nel ramdisk.
Se invece mi creo un file che tratto come un disco, cioe' lo inizializzo,
formatto e monto in loop, e su questo copio sia script che file di output,
aumento le performance o comunque ogni scrittura su questo filesystem
corrisponde ad una scrittura sul file fisico e quindi sul disco fisico?

 corrisponde ad una scrittura sul file fisico e quindi sul disco fisico?
Spiegami perche` non dovrebbe scrivere sul disco,
prima o poi... Come per ogni file...
Ho il sospetto che tu stia mescolando un po' di
cose in maniera non esatta.
Piuttosto, come ulteriore aiuto, esiste un tool,
iostat, che dovrebbe/potrebbe confermare/smentire
la tua ipotesi riguardo le prestazioni del disco.
bye,
-- 
piergiorgio

 bye,
Ciao


Ciao e grazie


tranquillo, il consiglio l'ho preso e la prova la faccio di sicuro. Non
fosse altro per togliermi il dubbio che serva a qualcosa
Grazie e ciao

 Dico bene o l'ho sparata grossa?
Io uso rrdtool con cacti e posso confermare che crea l'immagine "on-demand".
Enrico

 dischi scsi da 500gb in raid1 hw da 10000rpm.
Mmm... CPU? Attuale quantitativo di RAM? Presenza di LVM? Personalmente
sarei piu` propenso a:
- O a cambiare in toto la macchina (dipende da quanto sia performante
la/le CPU);
- O a provare a cambiare la modalita` RAID (da 1 a 0).
Creare un ramdisk e` utile, ma personalmente lo ritengo troppo
suscettibile a perdite di dati. Inoltre, sarebbe interessante sapere se
il controller RAID sia un vero controller, o se sia un fakeRAID (in
quest'ultimo caso, ti conviene passare al RAID software che, se non
ricordo male, e` piu` performante)
Enrico
P.S. se il numero di dischi lo permette (ovvero sono almeno 4), prova
anche con il RAID 10

 momenti di idle
Dovrebbe fare comunque e sempre cosi`.
Cioe` scrive in RAM finche` puo` e poi "scarica"
su disco, quando puo` o quando deve.
In questo senso, se il problema e` realmente il
disco, aumentare la RAM dovrebbe aiutare senza
ulteriori "ritocchi".
Inoltre, e` possibile fare il tuning del, come
si chiama?, "elevator"?, che gestisce il buffering
(ed altro credo) dello scheduler dei dischi.
In modo da gestire meglio/diversamente la RAM a
seconda di cosa il sistema deve fare.
bye,
-- 
piergiorgio

 No, se non e' un sintomo di problema
Controllare i log ed il disco, magari con smartctl (che chiede
a S.M.A.R.T. come sta il disco e di solito S.M.A.R.T. dice che
il disco e` rotto dopo che e` rotto, ma tant'e`...).
Avere una soluzione di backup, nel senso di "piano B" (e magari
anche "C"), nel caso succeda qualcosa.
bye,
-- 
piergiorgio

 
Dipende ovviamente dalla macchina, ma su un pc "recuperato" ad uso 
casalingo è quasi istantaneo, 1-2 sec ad immagine, ovvio su 300 immagini 
il tempo complessivo si fa sentire, tuttavia credo che su un server 
anche "normale" i tempi siano nettamente inferiori di questi.
Enrico

 problema.
Il punto di smartctl e` verificare (se possibile)
come stanno i dischi, il che non ha nulla ha che
vedere con il carico.
Il punto di iostat e` verificare quanto gli script
carichino l'I/O, per poter valutare eventuali problemi
dell'hardware.
Tutto qua, se mrtg e` pesante, sicuramente sara` il
colpevole della situazione.
bye,
-- 
piergiorgio

 
La butto li'.....
frazionare e mettere in cron 100 query ogni minuto creando 5 file di cfg 
per mrtg?
L'ho sparata proprio grossa?
Saluti.

 rognosi. 
No, il suo problema, almeno da quello che ho capito,
e` verificare che tutto sia in ordine e che non gli
sfugga il controllo della situazione hardware.
Non discuto che rrdtools sia meglio, ne` che mrtg sia
il colpevole, ma quello che lui vuole e` essere sicuro
che la macchina non riservi sorprese.
Se compili mrtg oppure installi rrdtools e` poi il
disco parte definitivamente, magari non si e` avuto
tutto questo vantaggio alla fine...
bye,
-- 
piergiorgio

 script di mrtg che prendevano sino a un minuto di tempo.
Così, giusto per intervenire colla mia solita cavolata, e senza voler
minimamente asserire che la pesantezza di quegli script non
costituisca un problema (non ne so nulla)...
Diciamo che oggi si usa un dual core a 3GHz. Rispetto al P100, 30
volte più veloce solo di clock; i core sono due, e fa 60... Vuoi che,
a parità di clock, un core di oggi non sia veloce almeno il doppio di
un P100[*]? Allora dovremmo più o meno esserci, a gestire due script
al secondo...
[*] Vedi anche, infatti:
http://freespace.virgin.net/roy.longbottom/dhrystone%20results.htm
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
__________________________________
Combatti l'AIDS col tuo computer: 
http://fightaidsathome.scripps.edu/

 Saluti.
Non mi sembra di vedere sostanziose differenze da quello che avviene adesso

Ragazzi siete stati fantastici non speravo ne credevo di ricevere tanto
interesse.
Ora devo staccarmi o il mio prossimo problema sara' con l'avvocato
divorzista.
Grazie a tutti e abuon rendere.
Ciao
  Nameci

 Sbaglio?
Rimani delle tue convinzioni.
I numeri secondo me sono abbastanza chiari.
Max