web-dev-qa-db-fra.com

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 de 125 G avec un pool de mémoire tampon InnoDB de 24 G 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 augmenter les performances et améliorer le débit d'E/S, j'ai décidé de remplacer innodb_flush_method Par O_DIRECT.

En référence à la documentation MySQL:

Lorsque les données et les fichiers journaux InnoDB se trouvent sur un SAN, il a été constaté que le réglage de innodb_flush_method Sur O_DIRECT Peut dégrader les performances des simples instructions SELECT 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 en utilisant innodb_flush_method=O_DSYNC. O_SYNC Et O_DSYNC Sont similaires à fsync() et fdatasync(): O_SYNC Synchronise les données et les métadonnées, tandis que O_DSYNC synchronise uniquement les données.

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_DIRECT Sera probablement le meilleur choix, selon votre application.

En recherchant sur Google, j'ai obtenu ceci rapport de référence: sur O_DSYNC Vs O_DIRECT

 Rapport d'analyse comparative: 
 =================== 
 Test transactionnel complexe à 1 ligne, 64 threads 
 
 * SAN O_DIRECT: demandes de lecture/écriture: 31560140 (8766,61 par seconde) 
 * SAN O_DSYNC: lecture/demandes d'é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 du disque local: lecture/demandes d'écriture: 4223757 (1173,04 par seconde.

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

Est-il bon de choisir O_DIRECT Plutô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 la mise à jour Rolando 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 en utilisant O_DIRECT, Je n'ai vu aucun 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> affiche des variables comme 'innodb_thread_concurrency'; 
 
 + --------------------------- + ------- + 
 | Nom_variable | Valeur | 
 + --------------------------- + ------- + 
 | innodb_thread_concurrency | 96 | 
 + --------------------------- + ------- + 
 1 ligne dans set (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: ACTIVE 
 PLUGIN_TYPE: MOTEUR DE STOCKAGE 
 PLUGIN_TYPE_VERSION: 50151.0 
 PLUGIN_LIBRARY: NULL 
 PLUGIN_LIBRARY_VERSION:. .] 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 ligne en jeu (0,00 s)
mysqlperformanceinnodbmysql-5.1redhat
12
Gopinath

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'étudier si quelque chose peut être fait du côté de MySQL - peut être d'ouvrir binlog avec O_DSYNC drapeau si sync_binlog=1 au lieu d'utiliser fsync vous aidera? Ou peut-être une pré-allocation binlog serait une bonne solution.

Pour l'instant, je ne connais personne qui ait abordé cette question. O_DSYNC par défaut n'est pas une perspective attrayante mais accepte des écritures plus rapides qui ne sont pas vraiment vérifiées. Voilà pourquoi il y a tant de battage médiatique autour de 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:

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:

7
RolandoMySQLDBA

J'ai toujours eu l'impression que O_DIRECT Est meilleur pour les performances car il 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 également de la charge de travail, que vous soyez en LECTURE ou en ÉCRITURE.

Aussi, question pour les experts: les appels supplémentaires à fsync() pour O_DIRECT Provoquent une dégradation notable des performances globales, ou est-ce négligeable? Je n'ai pas encore vu de repères le montrer.

Notez également que Percona a permis 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.

1
Derek Schultz