Welcome back. I've had a small bit of time off myself. At the moment I'm not convinced 10.6.9 has a fix for the spikes (as Marko would mark a likely duplicate on the JIRA if this was the case). My current running theory is that killed thread are resulting in the stall. Testing so far as resulted in memory leaks in the sysbench so I'm looking at re-implementing this. If its possible to deploy without your event KILL procedure that might prove a confirmation of theory while tests continue.

Are you sure db1111 wasn't affected? While it didn't loose grafana plots there are some correlations (and some anti-correlations) in the observed behaviours.

@Ladsgroup thanks for the perf recordings. I don't know of a good interactive measure. I'm sorry to say I couldn't see anything particularly insightful on them.

Looking into how it might be possible to grab stack traces for the next stall if it occurs.

If you've still got the perf base of the flamegraph, is a possible to get

perf report --no-children --stdio -i input.pef

1 is the default for innodb_flush_neighbours (just corrected docs). It doesn't really change to 0 on SSD detection as innodb ignores the setting if ssd was detected.

https://github.com/MariaDB/server/commit/10dd290b4b8b8b235c8cf42e100f0a4415629e79 shows an algorithm of autodetection based on /sys/block/*/queue/rotational contents.