Newsgroup: it.comp.hardware.storage
Titolo: Database ed SSD e Raid

Abbiamo un database che va lento, il problema pare essere l'accesso ai
dischi (che pure sono sei dischi SAS a 15k giri in raid0+1).
Stavo pensando di provare a prendere una coppia di X25 della Intel,
appoggiarcelo sopra, e vedere che succede, ma ho un po' di dubbi. Non
� che mi brucio subito tutte le celle dato che il numero di scritture
che vengono fatte sui dischi del database � alquanto elevato?
Mi chiedevo poi se il discorso raid cambia quando usi dei dischi SSD.

 che vengono fatte sui dischi del database è alquanto elevato?
No, AFAIK il problema non è questo. Esiste invece un problema di perdita
di prestazioni all'aumentare del numero di scritture (il disco a cui pensi
è comunque il meglio sul mercato, o lo era fino a poco fa). La soluzione
(che sta arrivando) è la funzione TRIM.
Per un'interessante panoramica, vedi se vuoi l'articolo
http://www.anandtech.com/storage/showdoc.aspx?i=3531
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 Mi chiedevo poi se il discorso raid cambia quando usi dei dischi SSD.
No il principio di funzionamento ï¿œ sempre quello...

 dischi (che pure sono sei dischi SAS a 15k giri in raid0+1).
Altra cosa che mi viene in mente, a prescindere dagli SSD: ma i journal
li tenete esterni, vero? Cioè proprio su altri dischi, rispetto al SAS?
Altrimenti, spostateli subito, e già dovreste vedere un miglioramento. 


 dischi (che pure sono sei dischi SAS a 15k giri in raid0+1).
Il database � vostro o vi � stato costruito da qualcuno?
Va lento in tutte le operazioni? In determinate selezioni di dati?
Analizzate prima cosa succede quando lanciate quelle query e vedete
quante righe vengono coinvolte e se i campi sono correttamente
indicizzati.
Passare da query che impiegano minuti a decimi di secondo non �
improbabile. Personalmente ho messo mano ad un elaborazione che con
tanti dati impiegava quasi 30 minuti. Adesso in 10/15 secondi hanno la
stessa cosa.
-- 
Freccia@Bulldozer63 :D

 stessa cosa.
Ellamadonna, 30 minuti? o_O... ma che avevano combinato?  :DD


http://www.anandtech.com/storage/showdoc.aspx?i=3531
Molto, molto, molto interessante! Grazie!

avete.
Beh, il database effettivamente � incazzoso (� quello di un gestionale
sap). 
Loro ci consigliano di prendere una SAN in fibra, per� � un giocattolo
da 30k euri. Se riusciamo a raggiungere prestazioni simili con un paio
di dischi SSD da 700 euro l'uno, ben venga!

Altrimenti, spostateli subito, e gi� dovreste vedere un miglioramento. 
Secondo me no... indagher�. Ma li posso appoggiare anche su dischi pi�
lenti? Tipo non so, dei dischi SATA su una NAS collegata tramite NFS?

stessa cosa.
Guardando nelle maintenace del sql 2005 su cui ci appoggiamo vedo che
non c'� altro che il full backup e i transaction log. Di
indicizzazioni e shrinking non c'� traccia. Ma io non mi azzardo a
metterci mano, sono solo un tecnico di rete e non ho le basi per fare
l'ottimizzazione di un database...

 l'ottimizzazione di un database...
E' quello che vi serve
Coi dischi al massimo andrai il doppio, il triplo, il quadruplo piu' veloce
Con delle query ottimizzate ed indici tarati ad hoc sulla vostra 
applicazione potete andare ben oltre questi miglioramenti
E' come dire, ho forato l'auto, aspetta che chiamo il carro attrezzi che 
cosi' faccio prima
Puo' anche essere, ma la soluzione sta nel cambiare la ruota, mica nel 
chiamare il carro attrezzi
Per sapere chi ha ragione tra venditori di hardware ed ottimizzatori di db 
basta che li metti uno contro l'altro, faranno loro il lavoro per te
Ciao
RobertoA

 di dischi SSD da 700 euro l'uno, ben venga!
Secondo me ï¿œ tutta una questione di otimizzazione del DB...non occorre
prendere soluzioni costose del genere.

 lenti?
Per stabilire quanto più lenti possano essere, per garantirti comunque
un vantaggio, credo si debbano tenere in conto dati fondamentali quali
il tipo di journaling (solo metadati, anche dati), le cache (va beh,
è tutto quanto protetto da UPS, no?) dei dispositivi su cui andranno i
journal etc.


 l'ottimizzazione di un database...
Ecco, stai alla larga dall'ottimizzatore di sql server. Lo avevamo provato
ai tempi di sql server 2000 e aveva creato degli indici alla cavolo di cane.
Molto meglio, che con il profiler, tracciate le query, poi con il query
analyzer le prendete una ad una, guardate l'execution plan e sistemate gli
indici di conseguenza.
Un cliente, aveva un maintenance plan che ogni notte gli compattava il
database, e sempre li a lamentarsi che il programma era lento. Gli avevamo
detto in tutte le lingue di togliere quel compattamento che faceva solo
casini. Nulla. Per i sistemisti interni di quella ditta il maintenance plan
era cosa buona e giusta. Poi, finalmente Dio vede e provvede. A novembre,
chiama una mattina che il database � esploso, occupa 30 gb in pi� e riempie
tutto il disco.
Controllo, una tabella da 4 milioni di record, che era esplosa. Questi
compattavano la tabella ogni notte. Periodicamente, viene lanciata una
procedura che fa insert/update su questa tabella. Durante una di queste
esecuzioni, l'ottimizzatore di sql server, trovando la tabella compattata e
vedendo che ogni volta che bisognava inserire un record c'erano da spostare
pagine di dati, ha pensato bene di scrivere un solo record per pagina.
Quindi 8k di dati per ogni record. Il tutto sull'indice clustered. Dopo che
sono rimasti fermi qualche ora, hanno deciso finalmente di ascoltarci e
disattivare quel piano di ottimizzazione.
Quindi, io eviterei i dischi ssd in quanto ho anche io qualche dubbio sul
numero limitato di scritture che supportano.
Prima verifica veloce: fai un backup del database tramite query analyzer. Al
termine del backup ti dice a che velocit� � andato. Il backup �
un'operazione di pura copia di dati che non coinvolge cpu, ram ecc, ed � un
misuratore se non preciso, ma abbastanza affidabile delle performance.
Dall'esperienza personale se facendo il backup dei dati leggendo e scrivendo
sullo stesso disco e hai:
- velocit� di 4/5 Mbyte al secondo, � il controller/dischi che fa schifo.
- velocit� di 20 Mbyte al secondo va benone.
- velocit� di 45/50 MByte al secondo (raggiunti da un cliente) vedi il
database che vola.
Per sql server � meglio avere i dati su dischi separati. Non un'unico volume
raid (anche se poi lo dividi in partizioni non cambia nulla).
Personalmente, quando posso, tengo i data file (.mdf) su un disco e il
transaction log (.ldf) su di un'altro disco.
In questo modo, riesci sempre a garantire una certa velocit� in scrittura.
Altra cosa: disattiva lo shrink automatico del db. Fai in modo che il data
file e il transaction log abbiano sembre una buona dose di spazio libero (un
compromesso pu� essere che ci sia lo spazio libero che andrebbero ad
occupare i dati nel giro di 3/4 mesi). Non � bello che si metta a fare un
grow mentre il programma fa una insert magari in mezzo ad una transazione.
Il grow, fallo manualmente tu (o tramite script) la sera o quando il
database � poco usato.
Lascia che il fill factor delle tabelle se lo gestisca sql server
(modificalo solo se sai e hai compreso per bene cosa questo comporta).
Lo spazio vuoto dentro al database non � spazio sprecato, specie nelle
tabelle che subiscono molte insert/update.
L'unica manutenzione che faccio, � quella di una volta alla settimana,
lanciare uno script come quello che trovi nel book online a proposito del
comando DBCC SHOWCONTIG, che fa una deframmentazione delle pagine dei dati.

 
Tranquillo che soprattutto quelli con celle SLC hanno un ciclo di
scrittura comparabile ad un HD tradizionale... tra l'altro giï¿œ
diverse aziende (anche importanti) cominciano finalmente ad 
utilizzarli.

 prendere soluzioni costose del genere.
� come prendere una F1 per correre nel campionao Kart :)
una spesa del genere sarebbe anche comprensibile ma
sarebbe interessante conoscere meglio i dettagli del resto del
sistema: con un sistema che costa 5K sarebbe strano consigliare
un sistema storage da 30K
per esempio non ho ben capito se "prima" andava bene
e ad un certo punto ha rallentato
Certo che i SAS 15k sono i migliori al momento ma ci sono
dischi e dischi senza trascurare il controller.
Per migliorare i tempi d'accesso potrebbe usare lo short stroking.
Sto facendo delle piccole prove e con 4 dischi 15K da 73GB in RAID-0
passo da 6ms a 4ms usando una partizione di soli 50GB  (12.5GB per disco)
sono migliorate le cose con gli SSD in RAID ?
luca


Migliorare in quale ambito? :)

 Ellamadonna, 30 minuti? o_O... ma che avevano combinato?  :DD
Bhe diciamo nel caso specifico c'� anche un discorso di fare le cose
diversamente per ottenere lo stesso risultato. Invece di lavorare di
codice ho scritto qualche query lunga una pagina, che per� appunto
andava bene. L'altra versione faceva migliaia di query ciclando record
per record.
Comunque con gli indici realmente si passa senza problemi da minuti a
frazioni di secondo.
Di norma, non avendone il tempo, creo le tabelle standard,
automaticamente si indicizzano le chiavi, quindi il grosso � fatto.
Poi quando mi rendo conto che qualche ricerca � lenta, vado a verificare
nello specifico.
-- 
Freccia@Bulldozer63 :D

 prendendo per il culo il mio capo.
Ah beh assolutamente tu non devi metterci le mani, il gestionale gira
sopra a quella versione del database. Toccare la struttura anche con un
solo indice non puoi farlo.
Anche perch� aprire un DB, dovresti poter vedere la struttura, capire
quali sono le tabelle nelle procedure lente, verificare che tipo di
query vengono fatte, cercare una soluzione. 
Insomma dovresti aver lavorato sui sorgenti.
-- 
Freccia@Bulldozer63 :D

passo da 6ms a 4ms usando una partizione di soli 50GB  (12.5GB per disco)
L'idea � buona, ma sfortunatamente mi manca lo spazio per farlo.

 richieste per organizzarsi il lavoro.
Lui intendeva dire se, in passato, vi sia mai stato
un periodo (non orario) in cui tutto funzionava.
Cioe`, senza rallentamente.
Comunque sia, immagino i collegamenti siano remoti,
cosa mi dici della rete?
Io ho visto rallentamenti abissali semplicemente
perche` un router ha avuto un "upgrade".
bye,
-- 
piergiorgio

journal etc.
Eh, vedi? Mi mancano le basi. E' meglio che l'ottimizzazione del
database SQL la lascio fare a qlc che ci sa pi� di me!

 database SQL la lascio fare a qlc che ci sa piï¿œ di me!
Quoto...ad ognuno il suo lavoro :))

solo indice non puoi farlo.
Eheheh no non c'� pericolo, non me lo sogno proprio di mettere le mani
su un oggetto complesso come quello se non sono pi� che sicuro di quel
che sto facendo... :D

 che sto facendo... :D
No appunto, � che anche se avessi nozioni di quel genere, e anche se lo
ottimizzeresti, semplicemente ci devono mettere le mani chi sviluppa.
Non era assolutamene una sorta di ramanzina :)
-- 
Freccia@Bulldozer63 :D

 L'idea � buona, ma sfortunatamente mi manca lo spazio per farlo.
che capacit� hanno i dischi e pi� o meno la dimensione del DB attuale ?
ciao
luca

 Migliorare in quale ambito? :)
forse ricordo male ma avevo letto che alcuni SSD non
rendevano bene con i controller in configurazione raid,
problema di firmware o di controller del disco SSD ...
forse erano i primi modelli ?
ciao
luca

 no flame raidSW vs raidHW pease :P
Ovviamente con un RAID SW non avrebbe avuto
questi problemi... :-)
Disclaimer: e` una battuta!
bye,
-- 
piergiorgio

 Disclaimer: e` una battuta!
lo-sa-pe-vo-che-fi-ni-va-co-s� ;)
luca


Probabilmente si trattava di problemi con le prime generazioni
di unitï¿œ SSD...