web-dev-qa-db-ja.com

innodb_flush_method = O_DIRECTとL_diskパーティションを使用したext3のO_DSYNCパフォーマンスへの影響

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

125Gのメインメモリには、instance1によって占有された24G InnoDBバッファープールと、instance2によって占有された12Gがあり、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（1秒あたり8766.61）
 * SAN O_DSYNC：読み取り/書き込み要求：5179457（1438.52 /秒）
 * SAN fdatasync：読み取り/書き込み要求：9445774（2623.66 /秒）
 *ローカルディスクO_DIRECT：読み取り/書き込み要求：3258595（905.06 /秒）
 *ローカルディスクO_DSYNC：読み取り/書き込み要求：3494632（970.65 /秒）
 *ローカルディスクfdatasync：読み取り/書き込みリクエスト：4223757（1173.04 /秒。

ただし、_O_DIRECT_はOSレベルのキャッシュを無効にします。この場合、ダブルキャッシュを無効にして、I/Oスループットを向上させることができます。

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

post で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 Plugins WHERE PLUGIN_NAME LIKE '％innodb％' AND PLUGIN_TYPE LIKE 'STORAGE ENGINE'\G 
 ***************** ********** 1.行*************************** 
 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 。] PLUGIN_AUTHOR：Innobase OY 
 PLUGIN_DESCRIPTION：トランザクション、行レベルのロック、および外部キーをサポートします
 PLUGIN_LICENSE：GPL 
 1行のセット（0.00秒）
mysqlperformanceinnodbmysql-5.1redhat
12
Gopinath

2009年1月21日、Peter Zaitsevは mysqlperformanceblog.com について次のように述べています。

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

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

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

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

これが完了したら、InnoDBを拡張して

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

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

7
RolandoMySQLDBA

_O_DIRECT_はダブルバッファリングを防ぐため、パフォーマンスには優れているといつも感じていました。また、バッテリバックアップ式ライトキャッシュを備えたハードウェアRAIDがある場合。もちろん、READとWRITEのどちらが重いかは、ワークロードにも依存します。

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

また、Perconaが_innodb_flush_method=ALL_O_DIRECT_を設定する機能を有効にしたことにも注意してください。これにより、InnoDBデータファイルだけでなく、InnoDBトランザクションログにも直接I/Oが提供されます。

1
Derek Schultz