Ho provato a cercare un benchmark sulle prestazioni di vari filesystem con MySQL InnoDB ma non sono riuscito a trovarne.
Il mio carico di lavoro del database è il tipico OLTP basato sul web, circa il 90% in lettura e il 10% in scrittura. IO casuale.
Tra i filesystem più diffusi come ext3, ext4, xfs, jfs, Reiserfs, Reiser4, ecc. Quale pensi sia il migliore per MySQL?
Risposte:
Quanto valuti i dati?
Scherzi a parte, ogni filesystem ha i suoi compromessi. Prima di andare molto oltre, sono un grande fan di XFS e Reiser entrambi, anche se eseguo spesso Ext3. Quindi non c'è un vero pregiudizio del filesystem al lavoro qui, solo per farti sapere ...
Se il filesystem è poco più che un contenitore per te, scegli quello che ti offre i migliori tempi di accesso.
Se i dati hanno un valore significativo, dovrai evitare XFS. Perché? Perché se non riesce a recuperare una parte di un file registrato su giornale , azzererà i blocchi e renderà i dati non recuperabili. Questo problema è stato risolto nel kernel Linux 2.6.22 .
ReiserFS è un file system eccezionale, a condizione che non si blocchi mai in modo anomalo . Il ripristino del journal funziona correttamente, ma se per qualche motivo perdi le informazioni sulla tua partizione o se i blocchi principali del filesystem vengono spazzati via, potresti avere un dilemma se ci sono più partizioni ReiserFS su un disco - perché il meccanismo di recupero analizza sostanzialmente il intero disco, settore per settore, cercando ciò che "pensa" sia l'inizio del filesystem . Se hai tre partizioni con ReiserFS ma ne viene soffiata solo una, puoi immaginare il caos che ciò causerà mentre il processo di recupero unisce un disastro di Frankenstein dagli altri due sistemi ...
Ext3 è "lento", in un "Ho 32.000 file e ci vuole tempo per trovarli tutti in esecuzione ls" in un certo senso. Se avrai migliaia di piccoli tavoli temporanei ovunque, avrai un po 'di dolore. Le versioni più recenti ora includono un'opzione di indice che riduce drasticamente l'attraversamento della directory ma può comunque essere dolorosa.
Non ho mai usato JFS. Posso solo commentare che ogni sua recensione che abbia mai letto è stata qualcosa del tipo "solido, ma non il bambino più veloce del blocco". Potrebbe meritare un'indagine.
Basta con i contro, diamo un'occhiata ai pro:
XFS:
ReiserFS:
ext3:
Quindi vedi, ognuno ha le sue stranezze. La domanda è: qual è il meno strano per te?
Vale anche la pena notare che è possibile eseguire InnoDB senza un file system e migliorare le prestazioni senza sovraccarico del file system. Non sono sicuro che lo consiglierei, ma l'ho usato prima senza problemi.
Inoltre, se stai eseguendo il 90% di letture e il 10% di scritture, a meno che tu non abbia bisogno della capacità transazionale di InnoDB, potresti cercare il porting su MyISAM per migliorare le prestazioni di lettura.
Le risposte qui sono gravemente deprecate e devono essere aggiornate in quanto ciò sta emergendo nei risultati di Google.
Per ambienti di produzione, XFS. Ogni volta. XFS è journaled e non bloccante. Assicurati di avere le seguenti variabili per un moderno database MySQL (2011/2012) che utilizza InnoDB in produzione:
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT
Non utilizzare EXT3 o EXT4. Un giorno BTRFS arriverà lì.
EXT3, e forse EXT4, si blocca a livello di inode, non è intelligente!
Fonti: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Comprensione di MySQL Internals di Sasha Pachev - https://www.facebook.com/note.php? note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - Alcuni kit altalena, prova ed errore.
EDIT: un aggiornamento. EXT4 sembra andare abbastanza bene a metà 2013! BTRFS non è ancora una buona opzione. E RHEL potrebbe rendere XFS il nuovo file system predefinito. Ancora una volta, NON utilizzare EXT3.
La versione breve è che la più vicina a una raccomandazione che ho visto fare da MySQL sui filesystem è XFS, tuttavia ext3 dovrebbe anche essere ok, ext4 promette di essere un bel miglioramento, ma non è ancora abbastanza stabile, anche se dovrebbe essere prima del fine anno.
Se stai eseguendo i file system del cluster CXFS, OCFS2 e GFS dovrebbero andare bene.
Avrei fortemente messo in guardia contro qualsiasi derivato Reiser e JFS anche se una volta bello è stato per lo più battuto da XFS ed ext4 che sono entrambi distribuiti più ampiamente.
Non è probabile che faccia molta differenza. Scegli quello che la tua distribuzione utilizza come predefinito, a condizione che sia sufficiente.
Spendi i tuoi sforzi sintonizzando altre cose - ottieni abbastanza ram - ottieni un controller raid che non fa schifo - e correggi l'uso lame (ab) del database dell'applicazione (NB: questo è il principale colpevole nella maggior parte dei casi in cui non lo ha già fatto è stato fatto).
Tuttavia, considera attentamente il filesystem su cui metti il tuo mysql tmpdir; questo influenzerà le prestazioni, in particolare le query che eseguono filesort () su disco (vedi EXPLAIN per maggiori dettagli).
Penso che un filesystem che supporti l'allocazione ritardata sia davvero utile qui, poiché puoi evitare completamente l'IO per i file di breve durata quando c'è abbastanza RAM per tenerli nella cache. XFS, ad esempio, non si preoccupa affatto di scrivere file che vengono eliminati e chiusi prima che siano stati allocati.
Ovviamente mettere un tmpdir su un tmpfs è interessante dal punto di vista delle prestazioni, ma comporta il rischio di esaurire lo spazio e di avere esito negativo le query che altrimenti avrebbero esito positivo (anche se con i file temporanei del disco).
Non trovo articoli recenti con "raccolte" di benchmark su MySQL in esecuzione su vari filesystem. Dato il carico di lavoro che descrivi, dubito che la frammentazione a livello di file costituirà un grosso problema. Senza un benchmark formale, non posso dire nulla che dovresti prendere come autorevole, ma il mio istinto dice che ogni filesystem che hai menzionato sopra funzionerà approssimativamente nello stesso ballpark (cioè tutti nello stesso ordine di grandezza per i numeri delle prestazioni) .
Il database sta davvero eseguendo lo spettacolo, dal momento che il filesystem sta semplicemente gestendo grandi estensioni a cui accede il motore di archiviazione.
Tuttavia, sarebbe interessante fare un riepilogo delle prestazioni con tutti quei filesystem. (Tuttavia, non ho nessun entusiasmo per MySQL, quindi non lo intraprenderò. Il benchmarking di Postgres, OTOH, potrebbe essere interessante ...)
IMHO il degno di nota degli FS disponibili per Linux sono:
XFS (scarsa velocità di lettura) noto per essere leggero sulle risorse di sistema e veloce con file di grandi dimensioni ma scarso per gestire molti file di piccole dimensioni.
ReiserFS (scarsa velocità di scrittura) non è molto gentile con le risorse di sistema ma funziona molto bene con molti file di piccole dimensioni.
EXT3 cade in mezzo, esibendosi accettabilmente su tutti i campi (il motivo per cui è stato considerato il FS di Linux predefinito ).
Non ho ancora usato EXT4, non ReiserFS4, ma ho dato un'occhiata ad alcuni benchmark e ReiserFS sembra avere le migliori prestazioni in termini di velocità di lettura, che hai detto essere la più importante per te.
Dai un'occhiata a questo: ReserFS4 X Ext4 X Ext3
Consiglierei Ext3 per la sua stabilità, sicurezza e maturità, ma se la velocità di lettura è la cosa più importante per te, dovresti prendere in considerazione ReiserFS.
Ricorda che dovresti anche considerare l'utilizzo della CPU, la stabilità, la sicurezza e così via prima di scegliere un FS.
E, naturalmente, realizzare un progetto pilota, test e analisi comparative sul tuo ambiente particolare è sempre il modo migliore per dire cosa funzionerà meglio per te.
PS: avrei pubblicato più benchmark ma non posso pubblicare più di un link.