Tag: ssd

在「Benchmark(et)ing with InnoDB redo log size」這邊看到在討論 InnoDB redo log 的大小對效能的影響 (也就是 innodb_log_file_size 與 innodb_log_files_in_group)。

開頭就有先提到重點，在新版 MySQL 裡，幾乎所有的情況比較大的 redo log 有比較好的效能 (平均值)：

tl;dr - conclusions specific to my test

1. A larger redo log improves throughput
2. A larger redo log helps more with slower storage than with faster storage because page writeback is more of a bottleneck with slower storage and a larger redo log reduces writeback.
3. A larger redo log can help more when the working set is cached because there are no stalls from storage reads and storage writes are more likely to be a bottleneck.
4. InnoDB in MySQL 5.7.17 is much faster than 5.6.35 in all cases except IO-bound + fast SSD

可以看出來平均效能的提昇很顯著，不管是增加 redo log 大小還是升級到 5.7：

但作者也遇到了奇怪的效能問題。雖然平均效能提昇得很顯著，但隨著加入資料的增加，效能的 degradation 其實很嚴重，在原來的網頁上可以看到這些資訊。

The results above show average throughput and that hides a lot of interesting behavior. We expect throughput over time to not suffer from variance -- for both InnoDB and for MyRocks. For many of the results below there is a lot of variance (jitter).

所以也許現階段先加大就好 (至少寫入的效能會提昇)，不需要把這個特性當作升級 MySQL 的理由。