Newsgroup: it.comp.os.linux.sys
Titolo: misura prestazioni con bonnie

ho un calcolatore che funge da server postgres... mi sembra "lento"
nonostante sia equipaggiato con 5Gb di ram e un raid scsi (raid5), e' un hp
proliant
l'esito del comando bonnie e' questo
Bonnie: Warning: You have 891MB RAM, but you test with only 100MB datasize!
Bonnie:          This might yield unrealistically good results,
Bonnie:          for reading and seeking and writing.
Bonnie 1.4: File './Bonnie.9601', size: 104857600, volumes: 1
Writing with putc()...         done:  45946 kB/s  97.6 %CPU
Rewriting...                   done: 630708 kB/s  98.6 %CPU
Writing intelligently...       done: 460504 kB/s  81.0 %CPU
Reading with getc()...         done:  55421 kB/s  98.7 %CPU
Reading intelligently...       done: 1515622 kB/s 100.7 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd
Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k
(03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec
%CPU
piffero 1* 100 45946 97.6460504 81.0 630708 98.6 55421 98.71515622  101
78469.8 62.8
ma non ho capito... bene...
cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      :                   Intel(R) Xeon(TM) CPU 3.00GHz
stepping        : 3
cpu MHz         : 3000.227
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm
constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips        : 6009.73
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:
cat /proc/meminfo
MemTotal:      5107144 kB
MemFree:         31500 kB
Buffers:         50304 kB
Cached:        4312028 kB
SwapCached:       1528 kB
Active:         655700 kB
Inactive:      4252772 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      5107144 kB
LowFree:         31500 kB
SwapTotal:     1052216 kB
SwapFree:      1041872 kB
Dirty:            1160 kB
Writeback:           4 kB
Mapped:         316552 kB
Slab:           142952 kB
CommitLimit:   3605788 kB
Committed_AS:   368660 kB
PageTables:       2788 kB
VmallocTotal: 34359738367 kB
VmallocUsed:     11896 kB
VmallocChunk: 34359725879 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB

 
Per esperienza personale ti posso dire che spesso si incontrano basi 
dati disegnate a cazzo che vengono accedute con query scritte col culo.
Detto questo avere RAID5 su un server su cui gira un RDBMS è una cagata 
nell 95% dei casi.
Devi capire dove sta il collo di bottiglia, cosa costa (nel senso 
algoritmico) di più, su quanti dati fai quali operazioni?? Le solite 
domande...

 nell 95% dei casi.
Sei sicuro di stare bene?
-- 
Per rispondermi, togli il nome del poeta

 Sei sicuro di stare bene?
Dimmi tutto =)

 nell 95% dei casi.
Temo che siano molto più diffusi di quanto tu creda. <g>

 domande...
si, in effetti mi sto organizzando per "piallare" la macchina, e
reinstallarla, senza il RAID... questo dovrebbe migliorare di parecchio le
performance, visto, per altro, che e' un raid software.

 
Che tipo di attività fa il DB (OLAP, OLTP) ?

 visto, per altro, che e' un raid software.
Oserei dire che per non trovare un raid software in un raid hardware,
devi spendere quelche migliaio di euro solo di scheda scsi dedicata,
perch่ tutte le altre, sono software, anche in server di marca e scsi...
Michele

 Dimmi tutto =)
Cosa dovrei dirti? Che hai detto un'ennesima cazzata? Il RAID 5 è la
soluzione tipica e standard per i dati.


 Il RAID 5 è la soluzione tipica e standard per i dati.
Qui in ufficio ho due colleghi, uno specializzato su DB2 e l'altro su
SQL Server, che si stanno rotolando per terra - mi hanno chiesto di
stampare il post e appenderlo alla porta dell'armadio nella zona
"infamie di della democrazia" (vuoi stare vicino a Silvio o al volantino
dei testimoni ? Di sicuro abbiamo cià deciso di mettere Zefram CocainOMEN).

 dei testimoni ? Di sicuro abbiamo cià deciso di mettere Zefram CocainOMEN).
Potresti argomentare meglio?
Non per polemica ma per semplice curiosità personale.
Ovviamente si parla di controller hardware seri (scsi, cache, tutto in hw)
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Che se io saprei che mio figlio mi diventerebbe un orecchione,
vivo glielo faccio mangiare il ritratto di Dorian Gray!
		-- Giorgio Faletti

 Ovviamente si parla di controller hardware seri (scsi, cache, tutto in hw)
Ovviamente, è molto semplice: il RAID5 è meno efficiente nello
scrivere/leggere i dati rispetto al RAID10, nel caso di letture
"piccole" è addirittura paragonabile alla velocità di un solo disco;
quindi, viste le dimensioni dei dischi attuali ed il costo per
MB,conviene fare array RAID 1 (tipicamente per i log o spazi
"temporanei") o 10.

 
ma il controller non dovrebbe sopperire alla lentezza? visto che stanno 
uscendo anche i raid 6 forse con soluzioni hw serie questa lentecca c'è e 
non c'è
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
In quanto a igiene lasciava molto a desiderare.  Pensa che gli offrirono
di reinterpretare "Quella sporca dozzina".  Da solo!
		-- Amurri & Verde

 questa lentecca c'è e non c'è
La lenteCCa non saprei, ma mentre una soluzione RAID6 può essere
indicata per un fileserver o simile, personalmente non la userei mai per
un DB. Per tanta ottimizzazione che hai difficilmente riesci a
compensare la perdita di prestazioni (pesante).
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 
quindi in questi casi meglio "sprecare" e fare un raid 1+0, giusto?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
La mia famiglia viveva in una tale miseria che quando finalmente siamo
diventati poveri abbiamo fatto una festa.
		-- Max Greggio

 quindi in questi casi meglio "sprecare" e fare un raid 1+0, giusto?
Come da manuale.

 quindi in questi casi meglio "sprecare" e fare un raid 1+0, giusto?
E' una "regola" matematica: più prestazioni vuoi più sprechi hai. :-)


Gordon Freeman ha scritto:

Per essere più chiaro (visto che sto cazzeggiando impunemente
nell'ultimo quarto d'ora della settimana) su un server di produzione medio:
OS (con swap) su array "A" in RAID1
DBLOG su array "B" in RAID1
DBDATA su array "C" in RAID10

 SQL Server, che si stanno rotolando per terra
Insieme al tuo cane, immagino.
C'è proprio poco da discutere, il RAID 5 è un ottimo compromesso per avere
affidabilità dei dati senza troppa inutile ridondanza. Quando l'hardware ti
assiste, usi RAID ADG/6/DP e simili, ma sono soluzioni proprietarie.
I tuoi colleghi farebbero bene a parlare di cose che conoscono e a conoscere
il contesto, e tu faresti meglio ad avere le palle di esporre una tua
opinione, se ce l'hai.


 scrivere/leggere i dati rispetto al RAID10
Che, ovviamente, non ha alcun problema di scalabilità e non riempie il bus
dati di traffico ed è banale da configurare con Linux, sopratutto se sei in
DAS, i cabinet si sa sono sempre vuoti.
Oppure tu parli di un sistema storage esterno, e in quel caso la tua
affermazione vale molto poco, perchè ogni sistema di storage è costruito in
un certo modo, e può rendere certe configurazioni migliori di altre o
viceversa. Nota anche che un RAID 10 non regge alla rottura contemporanea di
una qualsiasi coppia di dischi, mentre un RAID ADG sì.
Se ora ci spieghi da dove nasce il tuo "nel 95% dei casi RAID 5 non va bene"
te ne sarò grato. Ricordati che risposte del tipo "me l'hanno detto due che
ci capiscono più di me da cui sono andato a piangere quando ho fatto
l'ennesima figuraccia sul ng" non vanno bene.


Gordon Freeman wrote:

no, un'attivita' molto molto banale: gestisce, diciamo cosi', una specie di
enorme rubrica dove mi "segno" chi ha chiamato chi.