Newsgroup: it.comp.os.linux.sys
Titolo: Esperienze per filesystem per DB

Vi chiedevo che esperienza avevate nella scelta del fs per un db mysql.
 
Parliamo di un db di circa 50/55Gb (in crescita costante di 2Gb/mese) però senza 
particolari necessità di velocità in lettura, è un db di archivio perciò 
verranno effettuate al 99% delle scritture.
 
Vorrei abbandonare ext3 a favore di qualcosa di flessibile per la crescita senza 
arrivare ad lvm perchè mi sembra di complicarmi la vita inutilmente.
 
Pensavo a btrfs, mi date un parere?
 
Grazie
Rizio
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 Pensavo a btrfs, mi date un parere?
 
non saprei. 
Più che altro usa il journal del filesystem. Con ext4 lo fai con l'opzione 
di mount 'data=journal' e disattivi innodb_doublewrite (dovrebbe essere: 
skip-innodb_doublewrite) 
Dicono in giro che le prestazioni aumentano del 55% (non so se questo 
avviene con le bulk insert o in quale circostanza precisa, ma questo è 
quel che viene detto). 
 
-- 
Massimiliano Adamo

 Pensavo a btrfs, mi date un parere?
]zac[
 
[LUNGO]
 
btrfs Lo sto' valutando adesso, da come si sta' comportando direi che non 
e' 
piu' immaturo, e instabile.
Le prestazioni sono buone (vedi sotto) e sembra piuttosto stabile (non ho 
ancora iniziato in test veramente distruttivi).
 
Tiene conto che e' anche facile disattivare in un subvolume il COW, cosa 
che 
potrebbe essere utile se le prestazioni fossero scarse in certi usi, o per 
stressare meno un SSD.
 
Io ho quasi deciso di utilizzarlo come filesystem totale in un SSD, 
lasciando fuori solo i dati di parecchi GB.
 
 
 
Nei test e' interessante notare le prestazioni in scrittura superiori al 
massimo teorico grazie alla cache, il decadimento di prestazione nella 
lettura di file di piccoli dimensioni, il decadimento di prestazione nella 
sovrascrittura dei file (specialmente ext4).
 
 
Test di scrittura e lettura
 
SSD N1-SAMSUNG SSD 95 PRO   256GB  (molto veloci)
HD  WDC WD10PURX 64E5EY0      1TB  (veloci e silenziosi).
 
Filesystem appena formattato (tre partizioni, ext4, btrfs, 
xfs). 
Tutto di default, nessuna ottimizzazione.
 
Attenzione i tempi sono da prendere come indicativi e di confronto, 
ripetendo i test ci sono differenze del 10/20%.
 
A volte quando il comando di copia e' terminato, il disco continua a 
lavorare per alcuni secondi (forse e' sfruttata la ram anche per la 
scrittura, e viene ritardata la scrittura su disco, o e' 
l'autotaratura dei dischi).
 
Puo' essere utile fare la tara ai test confrontandoli con i dati di 
hdparm -tT
 
SSD
 
Timing cached reads:   33118 MB in  2.00 seconds = 16580.61 MB/sec 
Timing buffered disk reads: 6626 MB in  3.00 seconds = 2208.66 MB/sec
 
HD
 
Timing cached reads:   32974 MB in  2.00 seconds = 16509.17 MB/sec 
Timing buffered disk reads: 454 MB in  3.01 seconds = 151.00 MB/sec 
 
 
Test di scrittura
 
Copia di un file da 5GB da un HD WDC (la ram e' di 16GB, quindi la 
sorgente e' la ram, non l'HD), a un HD WDC o un SSD samsung.
 
      SSD                            WDC
 3,8''   1316 MB/sec    ext4     19''   263 MB/sec
 3,5''   1429 MB/sec    btrfs    20''   250 MB/sec   
 3,7''   1351 MB/sec    xfs      22''   227 MB/sec
 
 
Sovrascrittura del file.
 
     SSD                            WDC
 6,0''    833 MB/sec    ext4     37''   135 MB/sec
 3,8''   1318 MB/sec    btrfs    21''   238 MB/sec   
 3,7''   1351 MB/sec    xfs      23''   217 MB/sec
 
 
Per verifica e per fara la tara al test e' stata fatta la stessa 
operazione ma usando ' dd ' con bs=4K (con bs=512 btrsf 
impiega il doppio del tempo (invece ext4 e xfs impiegano poco tempo in 
piu').
 
      SSD                            WDC
 4,0''   1250 MB/sec    ext4     19''   263 MB/sec
 3,7''   1351 MB/sec    btrfs    20''   250 MB/sec   
 4,2''   1190 MB/sec    xfs      23''   217 MB/sec
 
 
Sovrascrittura del file.
 
     SSD                            WDC
 6,1''    820 MB/sec    ext4     37''   135 MB/sec
 4,0''   1250 MB/sec    btrfs    21''   238 MB/sec   
 4,2''   1190 MB/sec    xfs      23''   217 MB/sec
 
I tempi sono sostanzialmente coincidenti con il test usando ' cp '. 
 
 
Come sopra eccetto che e' la copia di una distribuzione linux di 5GB 
(quindi tanti file di medie/piccole dimensioni)
 
      SSD                            WDC
 7,0''    714 MB/sec    ext4     31''   161 MB/sec
10,3''    485 MB/sec    btrfs    40''   125 MB/sec   
15,1''    331 MB/sec    xfs      42''   119 MB/sec
 
 
Sovrascrittura del file.
 
     SSD                            WDC
16,1''    311 MB/sec    ext4     73''    68 MB/sec
20,8      240 MB/sec    btrfs    83''    60 MB/sec   
52,4       95 MB/sec    xfs     154''    32 MB/sec
 
 
 
zfs l'ho escluso perche' su SSD ha impiegato 2' e ha dato errore nella 
copia 
di alcuni permessi (ma ho usato il sistema in user space (zfs-fuse), magari 
il modulo per il kernel e' migliore).
 
 
 
Test di lettura
 
Copia di un file da 5GB su un filesystem in ram di 7,8GB da a un HD 
WDC o un SSD samsung.
 
      SSD                            WDC
 2,4''   2083 MB/sec    ext4     39''   128 MB/sec
 2,4''   2083 MB/sec    btrfs    39''   128 MB/sec   
 2,4''   2083 MB/sec    xfs      47''   106 MB/sec
 
Come sopra eccetto che e' la copia di una distribuzione linux di 5GB 
(quindi tanti file di medie/piccole dimensioni)
 
      SSD                            WDC
  13''    385 MB/sec    ext4     90''    56 MB/sec
  23''    217 MB/sec    btrfs    81''    62 MB/sec   
  37''    135 MB/sec    xfs     157''    32 MB/sec

 non e' piu' immaturo, e instabile.
 
test sicuramente validi ed interessanti, ma sicuramente validi in un 
ambito molto più generico e non nell'ambito ristretto del "filesystem per 
DB" richiesto dall'OP. 
Per questo io ho saltato la questione a piè pari dicendo: usa quel che ti 
pare. 
 
P.S.: vi risulta che sia stato risolto il problema del "no space left on 
device" causato dai chunk che si esauriscono e allora devi iniziare a far 
girare 20 volte: btrfs fi balance start -dusage=XX /  (cambiando di volta 
in volta XX)? 
A me è successo l'anno scorso. Dici che hanno risolto?
 
Giusto per capire di cosa parlo: 
http://bit.ly/218kDs1
 
 
 
-- 
Massimiliano Adamo

 quel che viene detto).
 
Le prestazioni non sono fondamentali, però se la macchina utilizza meno risorse 
mi va sempre bene :D


 stressare meno un SSD.
 
Come dicevo anche ad Adamo le prestazioni non sono il mio focus in questo 
momento ma è utile sapere che possono essere migliorate.


 momento ma è utile sapere che possono essere migliorate.
]zac[
 
Con i filesystem COW (copy on write) le prestazioni sono il focus, se cerchi 
alcuni test qualcuno ha rilevato prestazioni 10-100 volte inferiori a ext4.
 
E poi tendono a usare molto la RAM, a sprecare spazio su disco (infatti 
richiedono di pianificare periodiche manutenzioni online), una sicura 
strategia di backup, ecc. .
 
E sapere che si puo' disattivare il COW dove magari non serve allarga le 
possibilita' d'uso.
 
Bisogna avere uno scopo pratico per le opzioni del filesystem COW (che altri 
filesystem non hanno) altrimenti non ha molto senso usarli, i punti deboli 
finiscono per essere troppo in evidenza.
 
 
 
 
 

 Pensavo a btrfs, mi date un parere?
 
Cioè, non vuoi un volume manager che funziona per usare invece un file system e
volume manager che sarebbe ancora da considerare instabile? Se questo è il
ragionamento, allora l'unica risposta da darti è "usa ZFS e vivi felice"
 
Enrico

 il modulo per il kernel e' migliore).
 
Il modulo kernel è migliore. Decisamente:
 
[enrico@alice ~]$ sudo hdparm -tT /dev/sda
[sudo] password for enrico: 
 
/dev/sda:
 Timing cached reads:   9344 MB in  2.00 seconds = 4674.45 MB/sec
 Timing buffered disk reads: 308 MB in  3.02 seconds = 102.13 MB/sec
[enrico@alice ~]$ sudo hdparm -tT /dev/sd[a-d]
 
/dev/sda:
 Timing cached reads:   9628 MB in  2.00 seconds = 4816.95 MB/sec
 Timing buffered disk reads: 334 MB in  3.00 seconds = 111.21 MB/sec
 
/dev/sdb:
 Timing cached reads:   9266 MB in  2.00 seconds = 4635.65 MB/sec
 Timing buffered disk reads: 256 MB in  3.00 seconds =  85.23 MB/sec
 
/dev/sdc:
 Timing cached reads:   9514 MB in  2.00 seconds = 4759.87 MB/sec
 Timing buffered disk reads: 504 MB in  3.01 seconds = 167.54 MB/sec
 
/dev/sdd:
 Timing cached reads:   8404 MB in  2.00 seconds = 4203.42 MB/sec
 Timing buffered disk reads: 520 MB in  3.01 seconds = 172.87 MB/sec
[enrico@alice ~]$ sudo zpool status
  pool: storage
 state: ONLINE
  scan: scrub repaired 0 in 21h42m with 0 errors on Mon Feb 15 22:05:26 2016
config:
 
	NAME        STATE     READ WRITE CKSUM
	storage     ONLINE       0     0     0
	  raidz1-0  ONLINE       0     0     0
	    sdb3    ONLINE       0     0     0
	    sdc3    ONLINE       0     0     0
	    sdd3    ONLINE       0     0     0
	    sda3    ONLINE       0     0     0
 
errors: No known data errors
[enrico@alice ~]$ sudo zfs mount
storage/home                    /home
[enrico@alice ~]$ sudo dd if=/dev/zero of=test.raw bs=1M count=16384
16384+0 records in
16384+0 records out
17179869184
 bytes (17 GB) copied, 80.0893 s, 215 MB/s
[enrico@alice ~]$
 
Questo sul mio server di casa, un HP MicroServer Gen8 con 10Gb di RAM e ZFS su
Fedora 22
 
Enrico

 ragionamento, allora l'unica risposta da darti è "usa ZFS e vivi felice"
 
ZFS non lo conosco, il tuo parere sembra fondato epr lo meno per la parte che 
citi nell'altra mail e probabilmente vale la pena informarsi.


 Il modulo kernel è migliore. Decisamente:
]zac[
 
Si, e' un'altra cosa.
 
Comunque l'ho scartato per vari motivi:
- Nei test che si trovano in giro i rallentamenti di zfs e btrfs , in certe condizioni, rispetto a ext3/4 sono abbastanza simili.
- Con il codice lato userspace mi ha dato degli errori in alcuni attributi nella copia di una installazione di linux.
- Nel sistema di ripristino non e' gestito zfs, mentre btrfs viene visto automaticamente (quindi se il sistema non si avvia, con zfs e' probabile che sia una rogna risolvere, con btrfs spesso e' probabile che sia semplice sistemare.
 
 
 
Se interessa, aggiungo che ho scritto la prima parte degli script di manutenzione, in modo da fare lo scrub e il backup incrementale via send/receive di btrfs in automatico nelle operazioni pianificate (manca il purge dei vecchi dati di backup e il bilanciamento automatico).
 
Facendo le prove, ho copiato, cancellato file, directory, subvolume, snapshot per decine di GB e per varie volte, e non ho avuto problemi di spazio esaurito o perdita di spazio utilizzabile.
 
Direi che btrfs e' utilizzabile tranquillamente (una volta che ci si e' preso carico della manutenzione periodica), forse negli impieghi enterprise, critical, ad alto carico, potrebbe creare problemi (che non sono di poco conto, visto che attualmente non esiste un fsck offline serio).
 

 
 
Nei miei test btrfs non e' stato instabile, e' usabile tranquillamente.
Forse in usi particolari potrebbe dare problemi (e non esiste un fsck offline serio).
 
Io lo considero non instabile, ma non stabile (in tutte le occasioni).
Lo paragono ai primi ext3.

 Direi che btrfs e' utilizzabile tranquillamente
 
Punti di vista, per me un sistema che si pone come un rimpiazzo di tutto il
rimpiazzabile (accettabile, quando ne conosci i limiti) e non ha un sistema di
check del file system funzionante (inaccettabile), per me non è utilizzabile in
toto. Poi posso scendere anche a compromessi, ma per ora continuo a preferire
l'alternativa ZFS (che, per quanto mi piacerebbe il contrari, non lo userei
come  file system di root su Linux per ovvi motivi)
 
Enrico

Non ha senso continuare una discussione che mischia fatti concreti con gusti personali.
 
Discussione chiusa.