Qual è il miglior filesystem per inserire performance su PostgreSQL?

Sono curioso di sapere se qualcuno là fuori ha fatto esperimenti o confronti tra i file system e le prestazioni del database. Su Linux, mi chiedo quale sia il file system ottimale per un database Postgres. Inoltre, quali impostazioni (inode, ecc.) Sono ideali per questo? È qualcosa che può differire drasticamente in base ai dati nel database?

Se stai cercando una domanda relativa alle prestazioni generali del filesystem / database, questo post contiene alcune buone informazioni.

Tuttavia, vorrei ottenere il maggior numero possibile di consigli sulle prestazioni di inserimento anziché sulle prestazioni di lettura. Grazie per tutte le ottime risposte!

Acquista una copia di "postgresql high performance" di Greg Smith. È un ottimo libro e due o più capitoli riguardano Hardware disco e filesystem. Imparerai molto.

In breve: non c'è una risposta breve.

Ma proverò a summerize:

• non usare ext2 fino a quando non sai cosa stai facendo.
• con ext3 fai attenzione ai picchi di checkpoint a causa delle chiamate fsync, vedi pagina 113 e 82 e 79
• usa ext4 o xfs
• ci sono altre opzioni

Ma mentre ti stai davvero chiedendo quale FS utilizzare, dovresti leggere il libro!

Prima di tutto, vuoi prima un file system affidabile e un secondo veloce. Che esclude alcune opzioni ...

I test delle prestazioni mostrano che spesso XFS offre le migliori prestazioni. Ci sono alcuni problemi di stabilità quando si raggiungono scenari molto vicini al disco, ma finché si monitora che ciò non accada, si otterranno prestazioni leggermente migliori.

In teoria non è necessario un filesystem journaling per la directory pg_xlog, ma la differenza di velocità è di solito così piccola che non ne vale la pena. Per la directory dei dati, dovresti sempre avere un filesystem journaling per metadati.

I sistemi di gestione del database implementano il proprio journaling attraverso i registri del database, quindi l'installazione di tale DBMS su un file system journaled degrada le prestazioni attraverso due meccanismi:

1. Il journaling ridondante aumenta la quantità di attività del disco

2. Il layout del disco fisico può essere frammentato (sebbene alcuni file system di journaling abbiano meccanismi per ripulirlo).

3. Molte attività su disco possono riempire il giornale, causando condizioni "disco pieno" spurie.

Ho visto un'istanza alcuni anni fa in cui questo è stato fatto sul file system LFS su un'installazione Baan su una scatola HP / UX. Il sistema presentava persistenti problemi di prestazioni e corruzione dei dati che non venivano diagnosticati fino a quando qualcuno non ha scoperto che i file system erano formattati con LFS.

I volumi che contengono file di database avranno normalmente un numero limitato di file di grandi dimensioni. I server DBMS avranno normalmente un'impostazione che configura quanti blocchi vengono letti in un singolo I / O. Numeri più piccoli sarebbero appropriati per i sistemi di elaborazione delle transazioni ad alto volume in quanto ridurrebbero al minimo la memorizzazione nella cache dei dati ridondanti. Un numero maggiore sarebbe appropriato per sistemi come data warehouse che eseguivano molte letture sequetial. Se possibile, ottimizzare le dimensioni del blocco di allocazione del file system in modo che abbiano le stesse dimensioni della lettura a più blocchi su cui è impostato il DBMS.

Alcuni sistemi di gestione del database possono funzionare su partizioni del disco non elaborate. Ciò offre vari gradi di miglioramento delle prestazioni, in genere meno su un sistema moderno con molta memoria. Sui sistemi più vecchi con meno spazio per memorizzare nella cache i metadati del file system, i risparmi sull'I / O del disco erano piuttosto significativi. Le partizioni non elaborate rendono il sistema più difficile da gestire, ma offrono le migliori prestazioni disponibili.

I volumi RAID-5 comportano un sovraccarico di scrittura maggiore rispetto ai volumi RAID-10, quindi un database occupato con un sacco di traffico di scrittura funzionerà meglio (spesso molto meglio) su un RAID-10. I registri devono essere inseriti in volumi di dischi fisicamente separati nei dati. Se il database è di grandi dimensioni e per lo più di sola lettura (ad esempio un data warehouse), potrebbe esserci un caso per inserirlo in volumi RAID-5 se ciò non rallenta indebitamente il processo di caricamento.

La memorizzazione nella cache del write-back su un controller può darti una performance vincente a spese della creazione di alcune modalità di errore (ragionevolmente improbabili ma possibili) in cui i dati potrebbero essere danneggiati. La più grande vittoria in termini di prestazioni è rappresentata da carichi di accesso altamente casuali. Se si desidera eseguire questa operazione, prendere in considerazione l'inserimento dei registri su un controller separato e la disabilitazione della memorizzazione nella cache di riscrittura sui volumi dei registri. I log avranno quindi una migliore integrità dei dati e un singolo errore non è in grado di rimuovere sia i volumi di log che di dati. Ciò consente di ripristinare da un backup e di eseguire il roll forward dai registri.

Ho fatto una relazione così dettagliata ma è solo in francese . Se leggi il francese o sei soddisfatto degli strumenti di traduzione automatica ... Puoi riutilizzare la metodologia ed eseguirla tu stesso.

Riepilogo: ho usato pgbench. Lo scheduler I / O Linux ha poca importanza per le prestazioni e il filesystem solo un po '. Quindi, se hai fretta, scegli il valore predefinito. Ho scelto JFS.

Il filesystem è solo una parte del problema. È possibile ottenere un significativo aumento delle prestazioni modificando lo scheduler IO. Fortunatamente questo è abbastanza facile da testare in quanto è possibile cambiare lo scheduler IO al volo. Suggerirei di provare ognuno per un paio di giorni sotto carico tipico e vedere quale offre le migliori prestazioni.

Ho fatto alcuni test alcuni mesi fa:

Avevo un piccolo programma di test che creava 50 thread, in cui ogni thread inseriva 1000 (o se fosse 10000) righe nella stessa tabella.

• Con il database su EXT3 e un RAID5 a 4 dischi ci sono voluti 50 secondi.
• Con la tabella su ramdisk (usando tablespace) ci sono voluti ancora 50 secondi. Il motivo per cui non è stato più veloce è che tutto è registrato nella directory pg_xlog che era ancora sullo stesso RAID 5.
• Ho spostato pg_xlog su un RAID0 a 4 dischi (stripe) e lo stesso programma è stato eseguito in 40 secondi.
• A scopo di test ho spostato pg_xlog sul ramdisk e avevo tutto il resto sul RAID del disco EXT3 4. Il programma è terminato dopo meno di 5 secondi.

Ma avere pg___xlog su un ramdisk software non è un'opzione: se perdi il contenuto della directory pg_xlog postgres non si avvierà. (Ma esistono ramdisk hardware con backup della batteria che potrebbero essere di interesse.)

IMHO: usa il filesystem con cui ti senti più a tuo agio per i file di database. Spostare pg_xlog (con un collegamento simbolico, consultare la documentazione) sul dispositivo più veloce possibile.

Ho visto di aver ricordato che un FreeBSD ottimizzato ti darà un po 'più di prestazioni rispetto ad altri sistemi operativi. Anche se sono sicuro che questa informazione sia obsoleta e probabilmente un mito in primo luogo. Ma puoi provarlo comunque, vedi queste linee guida per le impostazioni del kernel: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html