innodb_flush_methodのいくつかの典型的な値 fsync: InnoDB は fsync() システム コールを使用して、データ ファイルとログ ファイルの両方をフラッシュします。fsync はデフォルト設定です。 O_DSYNC: InnoDB は、ログ ファイルを開いてフラッシュするために O_SYNC を使用し、データ ファイルをフラッシュするために fsync() を使用します。多くの種類の Unix で問題が発生しているため、InnoDB は O_DSYNC を直接使用しません。 O_DIRECT: InnoDB は O_DIRECT (または Solaris では directio()) を使用してデータ ファイルを開き、fsync() を使用してデータ ファイルとログ ファイルの両方をフラッシュします。このオプションは、一部の GNU/Linux バージョン、FreeBSD、および Solaris で使用できます。 値の取得方法については、MySQLの公式ドキュメントではこれを推奨しています 各設定がパフォーマンスに与える影響は、ハードウェア構成とワークロードによって異なります。ベンチマーク 特定の構成に応じて、どの設定を使用するか、またはデフォルト設定を維持するかを決定します。 Innodb_data_fsyncsステータス変数を調べて、fsync()呼び出しの総数を確認します。 各設定。ワークロード内の読み取り操作と書き込み操作の組み合わせによって、設定のパフォーマンスが影響を受ける可能性があります。 たとえば、ハードウェアRAIDコントローラとバッテリバックアップ書き込みキャッシュを備えたシステムでは、O_DIRECT InnoDBバッファプールとオペレーティングシステムのファイル間の二重バッファリングを回避するのに役立ちます。 システムキャッシュ。InnoDBデータとログファイルがSAN上に配置されている一部のシステムでは、デフォルトで SELECT文が中心の読み込み負荷の高いワークロードでは、値またはO_DSYNCの方が高速になる可能性があります。常に 実稼働環境を反映したハードウェアとワークロードでこのパラメータをテストします。 つまり、具体的な値はハードウェア構成とワークロードによって異なるため、ストレス テストを実行して決定するのが最適です。ただし、一般的に言えば、RAID コントローラとライトバック書き込みポリシーを備えた Linux 環境では、o_direct の方が適しています。ストレージ メディアが SAN の場合は、デフォルトの fsync または osync を使用する方が適している可能性があります。 一般的に言えば、ほとんどの人は、RAID カードを下部に配置し、読み取り/書き込みポリシーを write-back に設定して、値 o_direct を使用しているようです。 sysbench を使用して oltp タイプのストレス テストを行ったところ、o_direct は fsync よりもパフォーマンスが優れており、ほとんどのシナリオに適していることがわかりました。ただし、最近、このような SQL ステートメントに遭遇し、顧客からのフィードバックが非常に遅くなりました。同じメモリでは、それによって構築されたクラウド ホストは比較的高速に実行されました。その後、この大きなパフォーマンスの違いは、主に innodb_flush_method の設定値の違いによって引き起こされていることがわかりました。 テストシナリオ1 innodb_flush_methodはデフォルト値、つまりfsync、キャッシュプールは512M、テーブルデータ量は1.2Gで、キャッシュプールの影響を除いて、安定した結果です。 mysql> '%innodb_flush_me%' のような変数を表示します。 +---------------------+-------+ | 変数名 | 値 | +---------------------+-------+ | innodb_flush_method | | +---------------------+-------+ セット内の 1 行 (0.00 秒) mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main'; +--------------------------+ | SUM(結果)-SUM(収入) | +--------------------------+ |-191010.51 | +--------------------------+ セット1列目(1.22秒) mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main'; +--------------------------+ | SUM(結果)-SUM(収入) | +--------------------------+ |-191010.51 | +--------------------------+ セット1列目(1.22秒) mysql> explain SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main'; +----+-------------+---------+-------+---------------+-----------+--------+--------+------------------------+ | id | select_type | テーブル | タイプ | possible_keys | key | key_len | ref | 行 | 追加 | +----+-------------+---------+-------+---------------+-----------+--------+--------+------------------------+ | 1 | SIMPLE | journal | ref | account_id | account_id | 62 | const | 161638 | インデックス条件の使用 | +----+-------------+---------+-------+---------------+-----------+--------+--------+------------------------+ セット内の1行(0.03秒) テストシナリオ2 innodb_flush_methodがo_directに変更され、キャッシュプールの影響がなくなり、安定化後の結果 mysql> '%innodb_flush_me%' のような変数を表示します。 +---------------------+----------+ | 変数名 | 値 | +---------------------+----------+ | innodb_flush_method | O_DIRECT | +---------------------+----------+ セット内の 1 行 (0.00 秒) mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main'; +--------------------------+ | SUM(結果)-SUM(収入) | +--------------------------+ |-191010.51 | +--------------------------+ セット1列目(3.22秒) mysql> SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main'; +--------------------------+ | SUM(結果)-SUM(収入) | +--------------------------+ |-191010.51 | +--------------------------+ セット1列目(3.02秒) mysql> explain SELECT sql_no_cache SUM(outcome)-SUM(income) FROM journal where account_id = '1c6ab4e7-main'; +----+-------------+---------+-------+---------------+-----------+--------+--------+------------------------+ | id | select_type | テーブル | タイプ | possible_keys | key | key_len | ref | 行 | 追加 | +----+-------------+---------+-------+---------------+-----------+--------+--------+------------------------+ | 1 | SIMPLE | journal | ref | account_id | account_id | 62 | const | 161638 | インデックス条件の使用 | +----+-------------+---------+-------+---------------+-----------+--------+--------+------------------------+ セット内の 1 行 (0.00 秒) 結果の比較: 2 つの実行プランはまったく同じですが、パフォーマンスは大きく異なります。データベースを最初に起動したときのクエリ結果も大きく異なり、o_direct も大きく異なります (テスト結果は省略)。この場合、オペレーティング システムキャッシュの追加レイヤーによって読み取り効率が大幅に向上する理由がよくわかりません。本番環境の設定は、ストレス テストの結果と実際の効果に基づいて行う必要があり、経験値を盲目的に信頼することはできません。 改善策: innodb_flush_method を変更せずに、複合インデックス (account_id、outcome、income) を追加してカバーリング インデックス スキャンを実行することで、この SQL ステートメントをさらに最適化でき、応答時間を大幅に短縮できます。 上記のinnodb_flush_method値メソッド(例の説明)は、エディターが皆さんと共有するすべての内容です。 皆さんの参考になれば幸いです。 また、123WORDPRESS.COMを応援していただければ幸いです。 |
<<: Jenkins の紹介と Docker で Jenkins をデプロイする方法
>>: JavaScript キャンバスはマウスの動きに合わせてボールを動かすことを実装します
私はかつて、ウェブサイトを一度も構築したことのない人々が、初心者向けのウェブサイト構築方法に関する私...
ソフトウェアのグリーンバージョンとインストールバージョンの違いは何ですか?通常、ファイルのインストー...
VMware と Ubuntu を再インストールしましたが、コマンドラインプロンプトが単調すぎて美し...
目次序文スロークエリログの設定テスト付録: ログ解析ツール mysqldumpslow要約する序文こ...
目次整合性制約整合性制約の定義整合性制約の分類主キー制約単一の主キーと複合主キーの違い主キーフィール...
2つのケース: 1. 索引あり 2. 索引なし前提条件:方法: コマンドラインを使用してシミュレー...
データを挿入するとき、以前オフィス システムに取り組んでいたときにはデータベースのパフォーマンスにつ...
目次MySQL 削除構文エイリアスの問題mysql の delete ステートメントでエイリアスを使...
コードをコピーコードは次のとおりです。 <!DOCTYPE html PUBLIC "...
Docker で MySQL コンテナを作成する場合、コンテナの起動後にデータベースとテーブルが自動...
これは、よく使われるけれども忘れられがちな CSS 実装方法のコレクションです。抜けや追加があれば、...
1. 説明MySQLでは、テーブル内の行の総数を取得する必要がある場合、通常は次の文を使用します。 ...
背景: 一部の実験はサーバー上で完了する必要があります。したがって、リモート サーバー上のコードをロ...
1. Dockerに適したRedisのバージョンを見つけるdocker hubで見つけることができ...
プロキシを有効にする2つの方法React には、直接使用できるカプセル化された Ajax リクエスト...