MySQL InnoDB page_cleaner設定が最適でない可能性があります
Mysqld.logでこのメモを確認します。
[Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.)
このようなものについての言及がここにあるようです MySQLインスタンスが "SYNCインデックスを実行しています"ストールしています
私の質問は次のとおりです：このメモがログに表示された場合、実行する必要があるアクションはありますか？
MySQLとOSのバージョン：
mysql-community-server-5.7.9-1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64
推奨されるようにSHOW VARIABLES LIKE 'innodb％';を実行すると、次のようになります。
innodb_page_cleaners | 1
MySQL 5.7.8では、innodb_page_cleanersのデフォルト値が1から4に変更されました。ページクリーナースレッドの数がバッファープールインスタンスの数を超える場合、innodb_page_cleanersは自動的にinnodb_buffer_pool_instancesと同じ値に設定されます
Innodb_buffer_pool_instancesを確認するには：
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'
innodb_page_cleanersはinnodb_buffer_pool_instancesと同じ高さにのみ設定できます。 innodb_page_cleaners=4が必要な場合は、innodb_buffer_pool_instances=4も必要です。
さまざまなクライアントで同じ問題が発生しましたが、この問題はinnodb_lru_scan_depthの値をデフォルトの1024から128に設定したことが原因であることがわかりました。値を下げると、処理にかかる時間が短縮されます特に書き込み制限のあるワークロードでのトランザクションの場合、値を低く設定しすぎると、バッファープールがバッファーとバッファープールのダーティページの一部をクリアできなくなると考えています。
今回のケースでは、値を128から256に増やすことで大幅な改善が見られましたが、通常、適切な値はハードウェアと負荷のタイプによって異なります。トリックは、増加するOLTPパフォーマンスとMySQLにバッファプールをクリーンに維持させ、page_cleanerが多くの作業を行う必要がないようにする）間の正しい値を見つけることです、上記のメッセージで述べたように（"InnoDB：page_cleaner：1000ms意図されたループは15888msかかった"）。
MySQLを再起動せずに値を動的に変更できます。
SET GLOBAL innodb_lru_scan_depth=256;
このStackOverflowスレッドは便利です...
これは基本的に、DBで書き込みが多すぎてBufferPoolがダーティな値でいっぱいになることを意味します。これにより、PageCleanerがトリガーされ、ダーティページが機能してクリアされます。ダーティページが通常より多すぎるため、PageCleanerがバッファをクリアするのに時間がかかりました。
innodb_lru_scan_depth特定の変数は、クリアするために実行するバッファプールスキャンの量を制御します。これは大きな値であるか、システムの書き込みスループットが非常に高く、多数のダーティページを引き起こしている可能性があります。