MySQL压测⑤--压测后续之innodb_log_file_size取值探讨

前面的压测报告中最有趣的一张图莫过于这张波浪图了

TPS一次次的冲向波峰，然而没能持续多久就被拖到波谷，这个曲线对应的参数是innodb_log_file_size=100M

提取log查看当时的测试值

当该参数取1G和4G时的TPS则几乎一致，而取值100M的时候tps出现了明显的波动

当log_file_size取值太小时会有什么危害？

当一个日志文件写满后，innodb会自动切换到另外一个日志文件，而且会触发数据库的检查点（Checkpoint），这会导致innodb缓存脏页的小批量刷新，会明显降低innodb的性能。由于日志切换更频繁，也就直接导致更多的BUFFER FLUSH，由于日志切换的时候是不能BUFFER FLUSH的， BUFFER写不下去，导致没有多余的buffer 写redo， 那么整个MYSQL就HANG住，还有一种情况是如果有一个大的事务，把所有的日志文件写满了，还没有写完，这样就会导致日志不能切换（因为实例恢复还需要，不能被循环复写）这样mysql就hang住了

---

#2019.7.9补充

Innodb_log_file_size的取值

通常的做法是在高峰期算出MySQL在1分钟内产生的log量，然后估算出1小时的log量然后除以log组的组员数量，得到的便是Innodb_log_file_size值

对于Innodb_log_file_size过大的担心，主要在于recovery过程太久，但Innodb_log_file_size的值并不是recovery的唯一决定因素

---

log一小时的量计算方法

#测试的是一个线上库的从库（只过滤了26张表过来，数据量非常小）

pager grep sequence

#PAGER set to 'grep sequence'

show engine innodb status \G select sleep(60);show engine innodb status \G

#Log sequence number 719175320085

#1 row in set (0.00 sec)

#1 row in set (1 min 0.00 sec)

#Log sequence number 719175446230

#1 row in set (0.00 sec)

select (719175446230-719175320085) /1024 /1024 as MB_per_min;

+------------+

| MB_per_min |

+------------+

| 0.12030125 |

+------------+

1 row in set (0.00 sec)

可以看到，当前系统1分钟产生的log量约为0.12M，换算成1小时也不过7M左右，log组成员为3，算下来innodb_log_file_size也就是2.4M，对于这套系统，设置innodb_log_file_size=4M足以

---

备注

文章写于18年5月，之后便遗忘了，1年后的今天翻起来才发现这篇笔记没有写完，但是当初的压力测试环境已经没有了，因此没有办法对当初的那张测试图形进行很好的跟踪，有点遗憾

参考文档：innodb_log_file_size取值探讨