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_methodtoO_DIRECTpeut dégrader les performances desSELECTinstructions 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 ouO_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ù recommanderO_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)
Réponses:
De retour le 21 janvier 2009, Peter Zaitsev a déclaré ce qui suit sur mysqlperformanceblog.com
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 autourO_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
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 MySQLApr 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 Debianla source
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()desO_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.la source