2
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 …