innodb_flush_method = O_DIRECT vs. O_DSYNC-Leistungseinbußen bei ext3 mit LVM-Festplattenpartition

In einer meiner Produktionsumgebungen werden zwei Instanzen auf einem RedHat-Cluster ausgeführt, wobei eine Produktionsinstanz dem Cluster zugeordnet ist.

Wir haben 125 G Hauptspeicher mit 24 G InnoDB-Pufferpool, der von Instanz1 und 12 G von Instanz2 belegt ist, was nicht dem RedHat-Cluster zugeordnet ist. Sowohl die Daten- als auch die Transaktionsprotokolle befinden sich auf der LVM-Festplattenpartition mit einem ext3-Dateisystem.

Für eine Leistungssteigerung und einen besseren E / A-Durchsatz habe ich mich für den Wechsel innodb_flush_methodzu entschieden O_DIRECT.

Mit Bezug auf die MySQL-Dokumentation:

Wenn sich InnoDB-Daten und -Protokolldateien in einem SAN befinden, kann die Leistung einfacher Anweisungen durch die Einstellung innodb_flush_methodum den Faktor drei O_DIRECTbeeinträchtigt werden SELECT.

In Bezug auf die Hochleistungs-MySQL-Versionen 2 und 3 wurde angegeben, dass die Entwickler von InnoDB Fehler bei der Verwendung gefunden haben innodb_flush_method=O_DSYNC. O_SYNCund O_DSYNCsind ähnlich wie fsync()und fdatasync(): O_SYNCSynchronisiert sowohl Daten als auch Metadaten, wohingegen O_DSYNCnur Daten synchronisiert werden.

Wenn das alles nach vielen Erklärungen ohne Rat aussah, hier der Rat:

Wenn Sie ein Unix-ähnliches Betriebssystem verwenden und Ihr RAID-Controller über einen akkugepufferten Schreibcache verfügt, empfehlen wir die Verwendung O_DIRECT. O_DIRECTAndernfalls ist je nach Anwendung entweder die Standardeinstellung oder wahrscheinlich die beste Wahl.

Durch Googeln habe ich diesen Benchmark-Bericht erhalten: über O_DSYNCvsO_DIRECT

Benchmark-Bericht:
==================
Komplexer Transaktionstest für 1B-Zeilen, 64 Threads

 * SAN O_DIRECT: Lese- / Schreibanforderungen: 31560140 (8766,61 pro Sekunde)
 * SAN O_DSYNC: Lese- / Schreibanforderungen: 5179457 (1438,52 pro Sekunde)
 * SAN fdatasync: Lese- / Schreibanforderungen: 9445774 (2623,66 pro Sekunde)
 * O_DIRECT des lokalen Datenträgers: Lese- / Schreibanforderungen: 3258595 (905,06 pro Sekunde)
 * O_DSYNC der lokalen Festplatte: Lese- / Schreibanforderungen: 3494632 (970,65 pro Sekunde)
 * Fdatasync der lokalen Festplatte: Lese- / Schreibanforderungen: 4223757 (1173,04 pro Sek.

Allerdings O_DIRECTdeaktiviert den OS - Level - Cache, wo doppelte Caching deaktiviert werden kann , die einige bessere I / O - Durchsatz zeigen.

Ist es O_DIRECTbesser mit zu gehen als O_DSYNC? Diese beiden Optionen sind etwas verwirrend. Mit welcher Option kann ein besserer E / A-Durchsatz und eine bessere Leistung erzielt werden, ohne dass dies Auswirkungen auf die Daten, Lese- / Schreibvorgänge, insbesondere in der Produktion hat? Bessere Vorschläge aufgrund Ihrer persönlichen Erfahrung?

Ich konnte Rolando Update in der Post sehen :

Dennoch gibt es bei beiden Parametern leichte Verwirrung. Wo ich die meisten Produktionskonfigurationsvorlagen sehen konnte O_DIRECT, habe ich keine Empfehlungen gesehen O_DSYNC.

System

• MySQL 5.1.51-enterprise-gpl-pro-log
• Red Hat Enterprise Linux Server Version 5.5
• DELL DRAC mit RAID-Controller mit einem Akku-Rückschreibcache von 512 MB
• Dell PERC-Controller H700 mit einer Battery Backup Unit (BBU).

Zusätzliche Information

mysql> zeige Variablen wie 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
| Variablenname | Wert |
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 Reihe im Satz (0,00 Sek.) 

mysql> zeige Variablen wie 'innodb_read_io_threads'; 
Leerer Satz (0,00 Sek.) 

mysql> zeige Variablen wie 'innodb_write_io_threads'; 
Leerer Satz (0,00 Sek.)

Da wir das Standard-Plugin verwenden, habe ich die Informationen aus dem InnoDB-Status gepostet:

mysql> SELECT * FROM Plugins WHERE PLUGIN_NAME LIKE '% innodb%' UND PLUGIN_TYPE LIKE 'STORAGE ENGINE' \ G
*************************** 1. Reihe ********************* *******
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: STORAGE ENGINE
   PLUGIN_TYPE_VERSION: 50151.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase OY
    PLUGIN_DESCRIPTION: Unterstützt Transaktionen, Sperren auf Zeilenebene und Fremdschlüssel
        PLUGIN_LICENSE: GPL
1 Reihe im Satz (0,00 Sek.)

Zurück am 21. Januar 2009 erklärte Peter Zaitsev Folgendes auf mysqlperformanceblog.com

Als Handlungsaufforderung möchte ich sicherlich, dass jemand prüft, ob EXT3 in dieser Hinsicht behoben werden kann, da es mit Abstand das am weitesten verbreitete Dateisystem für Linux ist. Es lohnt sich auch zu untersuchen, ob auf MySQL-Seite etwas getan werden kann - kann es hilfreich sein, binlog mit O_DSYNCflag zu öffnen, sync_binlog=1anstatt fsync zu verwenden? Oder vielleicht binlog Vorbelegung wäre eine gute Lösung.

Bisher weiß ich, dass niemand dieses Thema angesprochen hat. O_DSYNCStandardmäßig ist dies kein ansprechender Aspekt, bietet jedoch Platz für schnellere Schreibvorgänge, die nicht wirklich überprüft wurden. Deshalb gibt es so viel Hype O_DIRECT.

Ich kann Ihnen sagen, dass Sie das InnoDB-Plugin nicht installiert haben. Mit dem InnoDB Plugin sollten mehrere Variablen existieren.

Sie sollten InnoDB auf zwei Arten aktualisieren:

• Upgrade auf MySQL 5.5 (Alle Verbesserungen des InnoDB-Plugins sind Teil von MySQL 5.5)
• Aktualisieren Sie das InnoDB-Plugin

Sobald Sie dies getan haben, können Sie InnoDB zu erweitern

• Zugriff auf mehr CPUs und Kerne
• Erhöhen Sie die Anzahl der Lese- und Schreibthreads
• Skalieren der E / A-Kapazität (dies wird insbesondere für verschiedene Speichermedien benötigt)

Hier sind meine letzten Beiträge zu den Einstellungen, die Sie dafür ändern können:

• Sep 12, 2011: Kann MySQL mehr als einen Kern verwenden?
• Sep 20, 2011: Multi-Cores und MySQL-Performance
• Apr 26, 2012: Ist die CPU-Leistung für einen Datenbankserver relevant?
• Mar 16, 2012: Verwenden mehrerer Kerne für einzelne MySQL-Abfragen unter Debian

Ich hatte immer den Eindruck, dass dies der O_DIRECTLeistung zuträglich ist, da doppelte Pufferung verhindert wird. Vorausgesetzt, Sie haben ein Hardware-RAID mit batteriegepuffertem Schreibcache. Natürlich hängt es auch von der Arbeitsbelastung ab, ob Sie READ oder WRITE schwer sind.

Auch Frage für die Experten: tun die zusätzlichen Anrufe fsync()für O_DIRECTUrsache eine spürbare Verschlechterung der Gesamtleistung, oder ist es unerheblich? Ich habe noch keine Benchmarks gesehen, die dies zeigen.

Beachten Sie auch, dass Percona die Möglichkeit zum Festlegen von innodb_flush_method=ALL_O_DIRECTdirekten E / A-Vorgängen nicht nur für InnoDB-Datendateien, sondern auch für InnoDB-Transaktionsprotokolle gleichzeitig aktiviert hat .