この問題は、データベースへの変更率が高いMySQLインスタンスに典型的なものです。 5GBのインポートを実行すると、ダーティページが急速に作成されます。ダーティページが作成されると、ページクリーナースレッドがダーティページをメモリからディスクにコピーします。
あなたの場合、5GBのインポートを常に行うわけではないと思います。したがって、これは非常に高いデータ負荷率であり、一時的なものです。 InnoDBは徐々に追いつくので、おそらく警告を無視することができます。
この警告につながる内部の詳細な説明は次のとおりです。
1秒に1回、ページクリーナーはバッファープールをスキャンしてダーティページを探し、バッファープールからディスクにフラッシュします。表示された警告は、フラッシュするダーティページがたくさんあり、それらのバッチをディスクにフラッシュするのに4秒以上かかり、1秒以内にその作業を完了する必要があることを示しています。言い換えれば、噛むことができる以上に噛み付いているのです。
innodb_lru_scan_depthを減らすことでこれを調整しました 1024から256に変更されました。これにより、ページクリーナースレッドが1秒に1回のサイクルでダーティページを検索するバッファプールまでの距離が短縮されます。あなたはそれをより小さなかみ傷を取るように求めています。
バッファプールインスタンスが多数ある場合は、フラッシュによってさらに多くの作業が行われることに注意してください。 innodb_lru_scan_depthを噛み砕きます 各バッファプールインスタンスの作業量。そのため、スキャン深度を減らさずにバッファプールの数を増やすことで、このボトルネックを誤って引き起こした可能性があります。
innodb_lru_scan_depthのドキュメント 「デフォルトよりも小さい設定は、通常、ほとんどのワークロードに適しています」と述べています。このオプションにデフォルトで高すぎる値を指定したようです。
innodb_io_capacityを使用して、バックグラウンドフラッシングで使用されるIOPSに制限を設けることができます。 およびinnodb_io_capacity_max オプション。最初のオプションは、InnoDBが要求するI/Oスループットのソフト制限です。ただし、この制限は柔軟です。フラッシュが新しいダーティページの作成速度に遅れをとっている場合、InnoDBはこの制限を超えてフラッシュ速度を動的に増加させます。 2番目のオプションは、InnoDBがフラッシュレートをどれだけ上げることができるかについてのより厳しい制限を定義します。
フラッシュの速度が新しいダーティページを作成する平均速度に追いつくことができれば、大丈夫です。ただし、ダーティページをフラッシュできるよりも速く一貫して作成すると、ダーティページがinnodb_max_dirty_page_pctを超えるまで、最終的にバッファプールがダーティページでいっぱいになります。 バッファプールの。この時点で、フラッシングレートは自動的に増加し、page_cleanerが警告を送信する可能性があります。
別の解決策は、より高速なディスクを備えたサーバーにMySQLを配置することです。ページのフラッシュで要求されるスループットを処理できるI/Oシステムが必要です。
平均的なトラフィックでこの警告が常に表示される場合は、このMySQLサーバーで書き込みクエリを実行しようとしている可能性があります。スケールアウトして、それぞれが独自のディスクシステムを持つ複数のMySQLインスタンスに書き込みを分割する時期かもしれません。
ページクリーナーの詳細：
- page_cleanerスレッドの紹介InnoDB （アーカイブされたコピー）
- MySQL-5.7はDML指向のワークロードを改善します