innodb_flush_method = O_DIRECTとLVMディスクパーティションのあるext3のO_DSYNCパフォーマンスへの影響

私の実稼働環境の1つでは、RedHatクラスター上で2つのインスタンスが実行されており、1つの実稼働インスタンスがクラスターに関連付けられています。

インスタンス1が占有する24G InnoDBバッファープールと、インスタンス2が占有する12Gの125Gメインメモリがあり、RedHatクラスターに関連付けられていません。データとトランザクションログは両方とも、ext3ファイルシステムのあるLVMディスクパーティションにあります。

パフォーマンスの向上とI / Oスループットの向上のために、に変更innodb_flush_methodすることにしましたO_DIRECT。

MySQLドキュメントを参照して：

InnoDBのデータファイルとログファイルがSAN上にある場合、に設定innodb_flush_methodするとO_DIRECT、単純なSELECTステートメントのパフォーマンスが3倍低下することがわかっています。

ハイパフォーマンスMySQL Ver 2および3を参照すると、InnoDB開発者がを使用してバグを発見したと述べていinnodb_flush_method=O_DSYNCます。O_SYNCとO_DSYNCに類似しているfsync()とfdatasync()：O_SYNC一方、同期データとメタデータの両方、O_DSYNCのみ同期データ。

それがアドバイスなしで多くの説明のように思えた場合、ここにアドバイスがあります：

Unixライクなオペレーティングシステムを使用しており、RAIDコントローラーにバッテリバックアップ式の書き込みキャッシュがある場合は、を使用することをお勧めしますO_DIRECT。そうでない場合は、O_DIRECTアプリケーションに応じて、デフォルトまたはおそらく最適な選択肢のいずれかです。

グーグルで、私はこのベンチマークレポートを得ました：オンO_DSYNC対O_DIRECT

ベンチマークレポート：
===================
1B行の複雑なトランザクションテスト、64スレッド

 * SAN O_DIRECT：読み取り/書き込み要求：31560140（8766.61毎秒）
 * SAN O_DSYNC：読み取り/書き込み要求：5179457（1438.52毎秒）
 * SAN fdatasync：読み取り/書き込み要求：9445774（毎秒2623.66）
 *ローカルディスクO_DIRECT：読み取り/書き込み要求：3258595（毎秒905.06）
 *ローカルディスクO_DSYNC：読み取り/書き込み要求：3494632（1秒あたり970.65）
 *ローカルディスクfdatasync：読み取り/書き込み要求：4223757（1秒あたり1173.04。

ただし、O_DIRECTOSレベルのキャッシュを無効にします。ダブルキャッシュを無効にすると、I / Oスループットが向上します。

O_DIRECTよりも一緒に行くのは良いO_DSYNCですか？これら2つのオプションは少しわかりにくいです。特に本番環境でデータ、読み取り/書き込みに影響を与えることなく、I / Oスループットの向上とパフォーマンスの向上を示すオプションはどれですか？あなたの個人的な経験に基づいたより良い提案はありますか？

投稿で Rolando Updateを見ることができました：

それでも、これらのパラメーターの両方にわずかな混乱があります。私が使用して生産の設定テンプレートのほとんどを見ることができた場合はO_DIRECT推薦ところ、私は任意のを見ていませんO_DSYNC。

システム

• MySQL 5.1.51-enterprise-gpl-pro-log
• Red Hat Enterprise Linux Serverリリース5.5
• バッテリーライトバックキャッシュ512MBのRAIDコントローラーを搭載したDELL DRAC
• バッテリーバックアップユニット（BBU）を搭載したDell PERCコントローラーH700。

追加情報

mysql> 'innodb_thread_concurrency'のような変数を表示します; 

+ --------------------------- + ------- +
| 変数名| 価値|
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
セット内の1行（0.00秒） 

mysql> 'innodb_read_io_threads'のような変数を表示します; 
空のセット（0.00秒） 

mysql> 'innodb_write_io_threads'のような変数を表示します; 
空のセット（0.00秒）

デフォルトのプラグインを使用しているため、InnoDBステータスから情報を投稿しました。

mysql> SELECT * FROMプラグインWHERE PLUGIN_NAME LIKE '％innodb％' AND PLUGIN_TYPE LIKE 'STORAGE ENGINE' \ G
*************************** 1.行******************** *******
           PLUGIN_NAME：InnoDB
        PLUGIN_VERSION：1.0
         PLUGIN_STATUS：アクティブ
           PLUGIN_TYPE：ストレージエンジン
   PLUGIN_TYPE_VERSION：50151.0
        PLUGIN_LIBRARY：NULL
PLUGIN_LIBRARY_VERSION：NULL
         PLUGIN_AUTHOR：Innobase OY
    PLUGIN_DESCRIPTION：トランザクション、行レベルのロック、および外部キーをサポート
        PLUGIN_LICENSE：GPL
セット内の1行（0.00秒）

2009年1月21日、Peter Zaitsevはmysqlperformanceblog.comで次のように述べました。

行動の呼びかけとして– EXT3はこれがLinuxで最も一般的なファイルシステムであるため、この点で修正できるかどうかを確認してください。また、MySQL側で何かできるかどうかを調査する価値があります。fsyncを使用O_DSYNCするsync_binlog=1代わりに役立つ場合は、フラグ付きのbinlogを開いているかもしれません。または、binlogの事前割り当てが良い解決策かもしれません。

まだ、この問題に触れた人はいません。O_DSYNCデフォルトは魅力的な見込みではありませんが、実際には検証されていない高速書き込みに対応しています。なぜそんなに誇大宣伝が周りにあるのかO_DIRECT。

InnoDBプラグインがインストールされていないことがわかります。InnoDBプラグインでは、いくつかの変数が存在するはずです。

次の2つの方法のいずれかでInnoDBをアップグレードする必要があります。

• MySQL 5.5へのアップグレード（すべてのInnoDBプラグインの機能強化はMySQL 5.5の一部です）
• InnoDBプラグインをアップグレードする

そうしたら、InnoDBを拡張して

• より多くのCPUとコアにアクセスする
• 読み取りおよび書き込みI / Oスレッドを増やす
• I / O容量をスケーリングします（これは特に異なるストレージメディアに必要です）

変更できる設定に関する過去の投稿は次のとおりです。

• Sep 12, 2011：MySQLに複数のコアを使用させることは可能ですか？
• Sep 20, 2011：マルチコアとMySQLパフォーマンス
• Apr 26, 2012：CPUパフォーマンスはデータベースサーバーに関連していますか？
• Mar 16, 2012：Debianでの単一のMySQLクエリに複数のコアを使用する

O_DIRECTダブルバッファリングを防ぐため、パフォーマンスが向上するという印象を受けていました。また、バッテリバックアップ式の書き込みキャッシュを備えたハードウェアRAIDがある場合。もちろん、それはワークロードにも依存します。あなたがREADかWRITEヘビーかです。

また、専門家への質問：全体的なパフォーマンスの顕著な低下fsync()をO_DIRECT引き起こす追加の呼び出しはありますか、それとも無視できますか？ベンチマークがこれを示すのをまだ見ていません。

また、Perconaはを設定する機能を有効にしているためinnodb_flush_method=ALL_O_DIRECT、InnoDBデータファイルだけでなく、InnoDBトランザクションログにも直接I / Oを提供します。