次のエディターは、innodb_flush_method 値メソッドに関する記事を提供します (例による説明)。編集者はこれがとても良いと思ったので、参考として共有します。編集者をフォローして、innodb_flush_method
rreeeの典型的な価値を見てみましょう。
つまり、特定の値はハードウェア構成とワークロードに関連しており、それを決定するにはストレス テストを実施するのが最善です。ただし、一般的に、RAIDコントローラー
とライトバック書き込み戦略を使用する Linux 環境では、o_direct がより良い選択です。ストレージ メディアが SAN の場合は、デフォルトの fsync または osync を使用する方が良い場合があります。
一般的には、値を o_direct に設定し、最下層に RAID カードがあり、読み取りおよび書き込みポリシーがライトバックに設定されていることが多いようです。 sysbench を使用して oltp タイプのストレス テストを行ったところ、o_direct は fsync よりもパフォーマンスが優れていることがわかりました。ただし、最近そのような SQL に遭遇し、その場合の顧客からのフィードバックは非常に遅かったです。同じメモリの場合、私が構築したクラウド ホストのパフォーマンスがはるかに速くなりました。後で、主な理由は innodb_flush_method の設定値の違いによって引き起こされた大きなパフォーマンスの違いであることがわかりました。 テストシナリオ1
innodb_flush_methodはデフォルト値であり、fsync、
cache
fsync: InnoDB uses the fsync() system call to flush both the data and log files. fsync is the default setting. O_DSYNC: InnoDB uses O_SYNC to open and flush the log files, and fsync() to flush the data files. InnoDB does not use O_DSYNC directly because there have been problems with it on many varieties of Unix. O_DIRECT: InnoDB uses O_DIRECT (or directio() on Solaris) to open the data files, and uses fsync() to flush both the data and log files. This option is available on some GNU/Linux versions,FreeBSD, and Solaris.
テストシナリオ 2innodb_flush_method を o_direct に変更し、キャッシュプールの影響を除外し、結果が安定しました
How each settings affects performance depends on hardware configuration and workload. Benchmark your particular configuration to decide which setting to use, or whether to keep the default setting. Examine the Innodb_data_fsyncs status variable to see the overall number of fsync() calls for each setting. The mix of read and write operations in your workload can affect how a setting performs. For example, on a system with a hardware RAID controller and battery-backed write cache, O_DIRECT can help to avoid double buffering between the InnoDB buffer pool and the operating system's file system cache. On some systems where InnoDB data and log files are located on a SAN, the default value or O_DSYNC might be faster for a read-heavy workload with mostly SELECT statements. Always test this parameter with hardware and workload that reflect your production environment
結果の比較:
2 つの実行計画は次のとおりです。まったく同じですが、パフォーマンスは大きく異なります。 database
を最初に起動したときの
queryの結果も大きく異なりますし、o_directも大きく異なります(
の結果は省略)。この場合、なぜ オペレーティング システム
キャッシュの追加層があるのかよくわかりません。そのため、実稼働環境の設定はストレス テストの結果と実際の結果に基づいている必要があります。経験値を盲目的に信じることはできません。改善策: innodb_flush_method を変更せずに、index(account_id,outcome,income) の組み合わせを追加することで、カバーするインデックス スキャンの応答を大幅に改善できます。時間【関連する推奨事項】1. Mysql の無料ビデオチュートリアル
2. MySQL での新しいユーザー権限の追加の詳細な例3. MySQL でのパスワードとアクセス制限の詳細な変更例
4. 正規表現を使用してデータベース内のコンテンツを置換する詳細な例 解決策
5.
mysqlに画像を保存するphpの例を詳しく解説以上がmysql の innodb_flush_method メソッドの詳細な例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。