前面的壓測(cè)報(bào)告中最有趣的一張圖莫過于這張波浪圖了
TPS一次次的沖向波峰赞厕，然而沒能持續(xù)多久就被拖到波谷，這個(gè)曲線對(duì)應(yīng)的參數(shù)是innodb_log_file_size=100M
提取log查看當(dāng)時(shí)的測(cè)試值
當(dāng)該參數(shù)取1G和4G時(shí)的TPS則幾乎一致据德，而取值100M的時(shí)候tps出現(xiàn)了明顯的波動(dòng)
當(dāng)log_file_size取值太小時(shí)會(huì)有什么危害般此？
當(dāng)一個(gè)日志文件寫滿后，innodb會(huì)自動(dòng)切換到另外一個(gè)日志文件链方，而且會(huì)觸發(fā)數(shù)據(jù)庫的檢查點(diǎn)（Checkpoint）持痰，這會(huì)導(dǎo)致innodb緩存臟頁的小批量刷新，會(huì)明顯降低innodb的性能祟蚀。由于日志切換更頻繁工窍，也就直接導(dǎo)致更多的BUFFER FLUSH，由于日志切換的時(shí)候是不能BUFFER FLUSH的前酿， BUFFER寫不下去患雏，導(dǎo)致沒有多余的buffer 寫redo， 那么整個(gè)MYSQL就HANG住罢维，還有一種情況是如果有一個(gè)大的事務(wù)淹仑，把所有的日志文件寫滿了，還沒有寫完肺孵，這樣就會(huì)導(dǎo)致日志不能切換（因?yàn)閷?shí)例恢復(fù)還需要匀借，不能被循環(huán)復(fù)寫）這樣mysql就hang住了
#2019.7.9補(bǔ)充
Innodb_log_file_size的取值
通常的做法是在高峰期算出MySQL在1分鐘內(nèi)產(chǎn)生的log量，然后估算出1小時(shí)的log量然后除以log組的組員數(shù)量平窘，得到的便是Innodb_log_file_size值
對(duì)于Innodb_log_file_size過大的擔(dān)心吓肋，主要在于recovery過程太久，但I(xiàn)nnodb_log_file_size的值并不是recovery的唯一決定因素
log一小時(shí)的量計(jì)算方法
#測(cè)試的是一個(gè)線上庫的從庫（只過濾了26張表過來初婆，數(shù)據(jù)量非常信钇隆）
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)
可以看到猿棉，當(dāng)前系統(tǒng)1分鐘產(chǎn)生的log量約為0.12M，換算成1小時(shí)也不過7M左右屑咳，log組成員為3萨赁，算下來innodb_log_file_size也就是2.4M，對(duì)于這套系統(tǒng)兆龙，設(shè)置innodb_log_file_size=4M足以
備注
文章寫于18年5月杖爽，之后便遺忘了，1年后的今天翻起來才發(fā)現(xiàn)這篇筆記沒有寫完紫皇，但是當(dāng)初的壓力測(cè)試環(huán)境已經(jīng)沒有了慰安，因此沒有辦法對(duì)當(dāng)初的那張測(cè)試圖形進(jìn)行很好的跟蹤，有點(diǎn)遺憾
