InnoDBは：page_cleaner：1000msでは、ループが4013msを取ったつもりでした。設定が最適ではないかもしれません。（= 1438フラッシュし、その間、0 =追い出さ。）
問題は、データベースへの変更の高い率を持っているMySQLインスタンスの典型的なものです。あなたの5ギガバイトのインポートを実行することにより、あなたは急速にダーティページを作成しています。ダーティページが作成されると、ページ・クリーナーのスレッドがメモリからディスクへのダーティページをコピーする責任があります。
あなたのケースでは、私はあなたが5ギガバイトの輸入のすべての時間をしないと仮定します。だから、これはデータロードの非常に高い割合であり、それは一時的です。InnoDBは徐々に追いつくますので、あなたはおそらく、警告を無視することができます。
ここでは、この警告につながる内部の詳細な説明があります。
毎秒たら、ページ・クリーナーは、バッファー・プールからディスクにフラッシュするダーティページのバッファー・プールをスキャンします。警告あなたはそれがフラッシュにダーティページの多くを持っていることを示しているのを見て、それが1秒未満でその作業を完了する必要がある場合、ディスクにそれらのバッチを洗い流すために4秒以上かかります。言い換えれば、それはオフにかむそれがかむことができるよりも多くのです。
あなたは減らすことによって、これを調整 innodb_lru_scan_depthを これはその一回あたりの第二サイクルの間にダーティ・ページ用のページ・クリーナースレッド検索をプールどこまでバッファに減少し1024から256に。あなたは小さな刺されを取ることを求めています。
あなたは多くのバッファプールのインスタンスがある場合、それはより多くの仕事をするためにフラッシュする原因となりますので注意してください。それはオフに刺さ innodb_lru_scan_depth 各バッファプールのインスタンスのための作業量を。だから、不注意スキャン深さを低下させることなく、バッファプールの数を増やすことで、このボトルネックの原因となった可能性があります。
ドキュメント innodb_lru_scan_depthは、 「デフォルト以外の設定に小さいが、ほとんどのワークロードのために一般的に適している。」と言います 彼らは、このオプションにデフォルトで高すぎるの値を与えたようですね。
あなたは、IOPSに制限を置くことができて、バックグラウンドのフラッシュが使用する innodb_io_capacity と innodb_io_capacity_max オプション。最初のオプションは要求しますI / OスループットのInnoDBのソフト制限です。しかし、この制限は柔軟性があります。フラッシュは、新しい汚れページ作成の割合の後ろに落下した場合、InnoDBは動的にこの制限を超える割合を洗い流す増加します。2番目のオプションは、InnoDBがフラッシング率が増加する可能性がありますどのくらいの厳しい制限を定義します。
フラッシュの速度は、新たな汚れのページを作成するの平均速度に追いつくことができるなら、あなたは大丈夫でしょう。あなたは一貫してより速く、彼らがフラッシュできるよりも、ダーティ・ページを作成する場合は、ダーティページを超えるまでしかし、最終的には自分のバッファプールは、ダーティページでいっぱいになります innodb_max_dirty_page_pct バッファプールのを。この時点で、フラッシングレートが自動的に増加し、再び警告を送信するためにpage_cleanerを引き起こす可能性があります。
別の解決策は、より高速なディスクを持つサーバーにMySQLを置くことであろう。あなたは、スループットを処理できるI / Oシステムは、あなたのページのフラッシュが要求する必要があります。
あなたは平均トラフィックの下で、この警告のすべての時間を参照してください場合は、このMySQLサーバ上であまりにも多くの書き込みクエリをやろうとしている可能性があります。スケールアウト、そして自分自身のディスクシステムで複数のMySQLインスタンスの上に書き込み、それぞれを分割するための時間かもしれません。
ページ・クリーナーについて詳しく読みます：
- InnoDB内の紹介page_cleanerスレッド （アーカイブされたコピー）
- MySQLの-5.7は、DML指向のワークロードを改善します
