innodb_flush_method = O_DIRECT vs O_DSYNC impatto sulle prestazioni su ext3 con partizione del disco LVM

In uno dei miei ambienti di produzione, abbiamo due istanze in esecuzione su un cluster RedHat, con un'istanza di produzione associata al cluster.

Abbiamo memoria principale 125G con pool buffer InnoDB 24G occupata dall'istanza 1 e 12G occupata dall'istanza2, che non è associata al cluster RedHat. Sia i dati che i registri delle transazioni si trovano sulla partizione del disco LVM con un file system ext3.

Per un aumento delle prestazioni e un migliore throughput I / O ho deciso di passare innodb_flush_methoda O_DIRECT.

Con riferimento alla documentazione MySQL:

Laddove i dati InnoDB e i file di registro si trovano su una SAN, è stato riscontrato che l'impostazione innodb_flush_methodsu O_DIRECTpuò degradare le prestazioni di SELECTistruzioni semplici di un fattore tre.

Facendo riferimento a MySQL Ver 2 e 3 ad alte prestazioni, ha dichiarato che gli sviluppatori di InnoDB hanno riscontrato errori nell'utilizzo innodb_flush_method=O_DSYNC. O_SYNCe O_DSYNCsono simili a fsync()e fdatasync(): O_SYNCsincronizza sia i dati che i metadati, mentre O_DSYNCsincronizza solo i dati.

Se tutto ciò sembrava un sacco di spiegazioni senza alcun consiglio, ecco il consiglio:

se si utilizza un sistema operativo simile a Unix e il controller RAID dispone di un writeecache con batteria, si consiglia di utilizzare O_DIRECT. In caso contrario, l'impostazione predefinita o O_DIRECTsarà probabilmente la scelta migliore, a seconda dell'applicazione.

Cercando su Google ho ottenuto questo rapporto di riferimento: su O_DSYNCvsO_DIRECT

Rapporto sui benchmark:
===================
Test transazionale complesso 1B Row, 64 thread

 * SAN O_DIRECT: richieste di lettura / scrittura: 31560140 (8766,61 al secondo)
 * SAN O_DSYNC: richieste di lettura / scrittura: 5179457 (1438,52 al secondo)
 * SAN fdatasync: richieste di lettura / scrittura: 9445774 (2623,66 al secondo)
 * Disco locale O_DIRECT: richieste di lettura / scrittura: 3258595 (905,06 al secondo)
 * O_DSYNC su disco locale: richieste di lettura / scrittura: 3494632 (970,65 al secondo)
 * Fdatasync del disco locale: richieste di lettura / scrittura: 4223757 (1173.04 al secondo.

Tuttavia, O_DIRECTdisabilita la cache a livello di sistema operativo, in cui è possibile disabilitare la doppia cache che mostra un throughput I / O migliore.

Va bene con O_DIRECTpiuttosto che con O_DSYNC? Queste due opzioni sono un po 'confuse. Quale opzione può mostrare un throughput I / O migliore e un miglioramento delle prestazioni senza alcun impatto sui dati, letture / scritture soprattutto nella produzione? Qualche suggerimento migliore basato sulla tua esperienza personale?

Ho potuto vedere Rolando Update nel post :

C'è ancora una leggera confusione su entrambi questi parametri. Dove ho potuto vedere la maggior parte dei modelli di configurazione di produzione usando O_DIRECT, non ho visto dove raccomandare O_DSYNC.

Sistema

• MySQL 5.1.51-enterprise-gpl-pro-log
• Red Hat Enterprise Linux Server versione 5.5
• DELL DRAC con controller Raid con una cache di riscrittura della batteria da 512 MB
• Controller Dell PERC H700 con una batteria di backup (BBU).

Informazioni aggiuntive

mysql> mostra variabili come 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
| Nome variabile | Valore |
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 riga nel set (0,00 sec) 

mysql> mostra variabili come 'innodb_read_io_threads'; 
Set vuoto (0,00 sec) 

mysql> mostra variabili come 'innodb_write_io_threads'; 
Set vuoto (0,00 sec)

Stiamo usando il plugin predefinito, quindi ho pubblicato le informazioni dallo stato di InnoDB:

mysql> SELEZIONA * DA Plug-in DOVE A PLUGIN_NAME COME '% innodb%' E A PLUGIN_TYPE COME 'STORAGE ENGINE' \ G
*************************** 1. riga ******************** *******
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ATTIVO
           PLUGIN_TYPE: MOTORE DI STOCCAGGIO
   PLUGIN_TYPE_VERSION: 50151.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase OY
    PLUGIN_DESCRIPTION: supporta transazioni, blocco a livello di riga e chiavi esterne
        PLUGIN_LICENSE: GPL
1 riga nel set (0,00 sec)

Il 21 gennaio 2009, Peter Zaitsev ha dichiarato quanto segue su mysqlperformanceblog.com

Come invito all'azione - Vorrei sicuramente che qualcuno vedesse se EXT3 può essere risolto in questo senso in quanto è di gran lunga il file system più comune per Linux. Vale anche la pena indagare se si può fare qualcosa sul lato MySQL - potrebbe aprire binlog con O_DSYNCflag se sync_binlog=1invece di usare fsync sarà di aiuto? O potrebbe essere pre-allocazione binlog sarebbe una buona soluzione.

Fino ad ora, non conosco nessuno che abbia toccato questo problema. O_DSYNCcome impostazione predefinita non è una prospettiva accattivante ma accetta scritture più veloci che non sono realmente verificate. Ecco perché c'è così tanto clamore in giro O_DIRECT.

Posso dirti che non hai installato il plugin InnoDB. Con il plug-in InnoDB, dovrebbero esistere diverse variabili.

È necessario aggiornare InnoDB in due modi:

• Esegui l'upgrade a MySQL 5.5 (tutti i miglioramenti del plug-in InnoDB fanno parte di MySQL 5.5)
• Aggiorna il plug-in InnoDB

Una volta fatto, puoi migliorare InnoDB a

• accedere a più CPU e core
• aumentare i thread I / O di lettura e scrittura
• ridimensionare la capacità I / O (questo è particolarmente necessario per diversi supporti di archiviazione)

Ecco i miei post precedenti sulle impostazioni che è possibile modificare per questo:

• Sep 12, 2011: È possibile fare in modo che MySQL utilizzi più di un core?
• Sep 20, 2011: Multi core e prestazioni MySQL
• Apr 26, 2012: Le prestazioni della CPU sono rilevanti per un server di database?
• Mar 16, 2012: Uso di più core per singole query MySQL su Debian

Ho sempre avuto l'impressione che O_DIRECTsia migliore per le prestazioni in quanto impedisce il doppio buffering. Inoltre, a condizione che si disponga di un RAID hardware con cache di scrittura supportata da batteria. Ovviamente, dipende anche dal carico di lavoro, che sia LEGGI o SCRIVI pesante.

Inoltre, domanda per gli esperti: le chiamate extra fsync()per O_DIRECTcausare un notevole degrado delle prestazioni complessive o è trascurabile? Devo ancora vedere i benchmark che mostrano questo.

Inoltre, si noti che Percona ha abilitato la possibilità di impostare innodb_flush_method=ALL_O_DIRECT, che fornisce I / O diretto non solo sui file di dati InnoDB, ma anche sui registri delle transazioni InnoDB allo stesso tempo.