Comment 25 for bug 1844929

> I'm trying out a DNM devstack patch [2] to set innodb_lru_scan_depth=256 and keep rechecking the DNM nova change [3] to see if it has any effect on the failures.

Well, this seems to have the opposite of the desired effect [4]:

2020-03-12T22:59:10.304511Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 7728ms. The settings might not be optimal. (flushed=30 and evicted=0, during the time.)
2020-03-12T22:59:33.848105Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 11540ms. The settings might not be optimal. (flushed=1 and evicted=0, during the time.)
2020-03-12T23:00:23.206041Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 11356ms. The settings might not be optimal. (flushed=1 and evicted=0, during the time.)
2020-03-12T23:00:44.698049Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 8507ms. The settings might not be optimal. (flushed=7 and evicted=0, during the time.)
2020-03-12T23:01:21.877705Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 6176ms. The settings might not be optimal. (flushed=17 and evicted=0, during the time.)

but at least I can see the setting change did something.

It also happened to not fail the job run either. I'm going to try out some other settings related to the buffer pool next.

[1] https://stackoverflow.com/questions/41134785/how-to-solve-mysql-warning-innodb-page-cleaner-1000ms-intended-loop-took-xxx
[2] https://review.opendev.org/712805
[3] https://review.opendev.org/701478
[4] https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_18a/701478/5/check/grenade-py3/18a9555/controller/logs/mysql/error_log.txt