innodb_flush_method = Impact des performances O_DIRECT vs O_DSYNC sur ext3 avec partition de disque LVM

Dans l'un de mes environnements de production, nous avons deux instances exécutées sur un cluster RedHat, avec une instance de production associée au cluster.

Nous avons une mémoire principale 125G avec un pool de mémoire tampon InnoDB 24G occupé par instance1 et 12G occupé par instance2, qui n'est pas associé au cluster RedHat. Les données et les journaux de transactions se trouvent sur la partition de disque LVM avec un système de fichiers ext3.

Pour une amélioration des performances et un meilleur débit d'E / S, j'ai décidé de passer innodb_flush_methodà O_DIRECT.

En référence à la documentation MySQL:

Lorsque les données et les fichiers journaux InnoDB sont situés sur un SAN, il a été constaté que le paramètre innodb_flush_methodto O_DIRECTpeut dégrader les performances des SELECTinstructions simples par un facteur de trois.

Se référant à MySQL haute performance Ver 2 et 3, il a déclaré que les développeurs InnoDB ont trouvé des bogues avec l'utilisation innodb_flush_method=O_DSYNC. O_SYNCet O_DSYNCsont similaires à fsync()et fdatasync(): O_SYNCsynchronise les données et les métadonnées, tandis que les O_DSYNCdonnées sont synchronisées uniquement.

Si tout cela ressemblait à beaucoup d'explications sans conseil, voici le conseil:

si vous utilisez un système d'exploitation de type Unix et que votre contrôleur RAID dispose d'un cache écrit alimenté par batterie, nous vous recommandons d'utiliser O_DIRECT. Sinon, la valeur par défaut ou O_DIRECTsera probablement le meilleur choix, selon votre application.

Par googler, j'ai obtenu ce rapport de référence: sur O_DSYNCvsO_DIRECT

Rapport de référence:
===================
Test transactionnel complexe 1B Row, 64 threads

 * SAN O_DIRECT: demandes de lecture / écriture: 31560140 (8766,61 par seconde)
 * SAN O_DSYNC: demandes de lecture / écriture: 5179457 (1438,52 par seconde)
 * SAN fdatasync: demandes de lecture / écriture: 9445774 (2623,66 par seconde)
 * Disque local O_DIRECT: demandes de lecture / écriture: 3258595 (905,06 par seconde)
 * Disque local O_DSYNC: demandes de lecture / écriture: 3494632 (970,65 par seconde)
 * Fdatasync sur disque local: demandes de lecture / écriture: 4223757 (1173,04 par sec.

Cependant, O_DIRECTdésactive le cache au niveau du système d'exploitation, où la double mise en cache peut être désactivée, ce qui affiche un meilleur débit d'E / S.

Est-il bon d'y aller O_DIRECTplutôt que O_DSYNC? Ces deux options sont un peu déroutantes. Quelle option peut montrer un meilleur débit d'E / S et une amélioration des performances sans aucun impact sur les données, en lecture / écriture, en particulier en production? De meilleures suggestions basées sur votre expérience personnelle?

J'ai pu voir Rolando Update dans le post :

Il y a toujours une légère confusion sur ces deux paramètres. Là où j'ai pu voir la plupart des modèles de configuration de production à l'aide O_DIRECT, je n'ai vu aucun endroit où recommander O_DSYNC.

Système

• MySQL 5.1.51-enterprise-gpl-pro-log
• Red Hat Enterprise Linux Server version 5.5
• DELL DRAC avec contrôleur RAID ayant un cache de réécriture de batterie 512 Mo
• Contrôleurs Dell PERC H700 avec unité de sauvegarde sur batterie (BBU).

Information additionnelle

mysql> afficher des variables comme 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
| Nom_variable | Valeur |
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 rangée en jeu (0,00 sec) 

mysql> afficher des variables comme 'innodb_read_io_threads'; 
Ensemble vide (0,00 sec) 

mysql> afficher des variables comme 'innodb_write_io_threads'; 
Ensemble vide (0,00 sec)

Nous utilisons le plugin par défaut, j'ai donc publié les informations sur le statut InnoDB:

mysql> SELECT * FROM Plugins WHERE PLUGIN_NAME LIKE '% innodb%' ET PLUGIN_TYPE LIKE 'STORAGE ENGINE' \ G
*************************** 1. rangée ******************** *******
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIF
           PLUGIN_TYPE: MOTEUR DE STOCKAGE
   PLUGIN_TYPE_VERSION: 50151.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase OY
    PLUGIN_DESCRIPTION: prend en charge les transactions, le verrouillage au niveau des lignes et les clés étrangères
        PLUGIN_LICENSE: GPL
1 rangée en jeu (0,00 sec)

De retour le 21 janvier 2009, Peter Zaitsev a déclaré ce qui suit sur mysqlperformanceblog.com

Comme appel à l'action - j'aimerais sûrement que quelqu'un voie si EXT3 peut être corrigé à cet égard car c'est de loin le système de fichiers le plus courant pour Linux. Il vaut également la peine d'examiner si quelque chose peut être fait du côté de MySQL - peut-être ouvrir binlog avec O_DSYNCindicateur si sync_binlog=1au lieu d'utiliser fsync vous aidera? Ou peut-être une pré-allocation binlog serait une bonne solution.

Pour l'instant, je ne connais personne ayant abordé cette question. O_DSYNCpar défaut, ce n'est pas une perspective attrayante, mais permet des écritures plus rapides qui ne sont pas vraiment vérifiées. C'est pourquoi il y a tellement de battage médiatique autour O_DIRECT.

Je peux vous dire que le plug-in InnoDB n'est pas installé. Avec le plugin InnoDB, plusieurs variables devraient exister.

Vous devez mettre à niveau InnoDB de deux manières:

• Mettre à niveau vers MySQL 5.5 (Toutes les améliorations du plug-in InnoDB font partie de MySQL 5.5)
• Mettre à niveau le plugin InnoDB

Une fois que vous l'avez fait, vous pouvez améliorer InnoDB pour

• accéder à plus de CPU et de cœurs
• augmenter les threads d'E / S en lecture et en écriture
• faire évoluer la capacité d'E / S (ceci est particulièrement nécessaire pour différents supports de stockage)

Voici mes précédents articles sur les paramètres que vous pouvez modifier pour cela:

• Sep 12, 2011: Possible de faire utiliser MySQL plus d'un core?
• Sep 20, 2011: Multi-cœurs et performances MySQL
• Apr 26, 2012: Les performances du processeur sont-elles pertinentes pour un serveur de base de données?
• Mar 16, 2012: Utiliser plusieurs cœurs pour des requêtes MySQL uniques sur Debian

J'ai toujours eu l'impression que O_DIRECTc'était mieux pour les performances car cela empêche la double mise en mémoire tampon. En outre, à condition que vous disposiez d'un RAID matériel avec un cache d'écriture alimenté par batterie. Bien sûr, cela dépend aussi de la charge de travail, que vous soyez lourd en lecture ou en écriture.

En outre, la question pour les experts: faire des appels supplémentaires à fsync()des O_DIRECTcauses d' une dégradation notable de la performance globale, ou est - il négligeable? Je n'ai pas encore vu de repères le montrer.

Notez également que Percona a activé la possibilité de définir innodb_flush_method=ALL_O_DIRECT, qui fournit des E / S directes non seulement sur les fichiers de données InnoDB, mais également sur les journaux de transactions InnoDB en même temps.