今回は、MySQLのREDOログを使い切ってしまった場合にどんな悲劇が訪れるか、
というのをグラフで見てみようと思います。
今回テストした環境はこんな感じです。
CentOS 6.5 MySQL 5.7.20 innodb_adaptive_flushing_lwm=30 innodb_log_file_size=100M innodb_log_files_in_group=2 innodb_max_dirty_pages_pct=75 sysbench 1.0.9 テスト: /usr/share/sysbench/oltp_write_only.lua
他のサーバからsysbenchで書き込み負荷をかけてみて、
MySQLのTPSがどうなるか、というのを見てみようというわけです。
早速ですが、結果はこんな感じでした。
テスト開始15秒ほどから180秒間sysbenchの負荷をかけています。
LSNはシンプルにバイト数を表しているそうですので、
Log sequence number – Last checkpoint atで、
どのくらいまだデータファイルに適用していないREDOログがあるかわかります。
MySQLでは、REDOログを全部使い切るような事態になる前に、
新規書き込み要求よりもREDOログのフラッシュを優先するようになりますが、
この結果はそれを裏付けているといえます。
TPS vs LSNの結果では、
概ね70%ほどREDOログを使った時点で(REDOログの最大サイズは100MB × 2 = 200MB)、
TPSが急落していますので、
これがアプリケーションのある通常のシステムであれば、
ユーザーからみて処理が重たくなっているであろうことが推察されます。
REDO使用率70%ほどになってからしばらくはREDOログのフラッシュがかなり優先され、
その結果REDOログ使用率は50%くらいまで持ち直しています。
その後、50%の使用率で安定し、
TPSが0になった時点(ここでsysbenchを停止しました)で、
改めて残りのREDOログをフラッシュする、
という挙動を見せています。
ただし、ここは少し自信ないのですが、
REDOログ使用率が50%程度の時には、
要はREDOログのデータファイルへのフラッシュ量と、
新規REDOログへの書き込み量が釣り合っているということなので、
それではREDOログがパフォーマンス上の緩衝材の役割を果たせていない、
ということを意味していると考えています。
一方、TPS vs Disk busy ratioのグラフを見てみると、
最初sysbenchの負荷をかけている時点では、
当然ながらディスクのビジー率は90%以上で、
かなりの高負荷です。
これはREDO使用率が70%に達し、
REDOログのフラッシュが優先されるようになってからも同様です。
一方、sysbenchの負荷をかけ終わり、
REDOログのフラッシュをするフェーズに入ると、
%utilは10%弱程度なので、
暇さえあれば全力でフラッシュをする仕様というわけではないと推定されます。
これらの結果を見てわかる通り、
REDOログの枯渇はパフォーマンスに深刻な(TPSベースで言って1/5程度)
悪影響を与えます。
これを避けるためには、1にも2にも、
innodb_log_file_sizeを上げることです。
ib_logfileのサイズを大きくする、というのは、
クラッシュリカバリの時間が長くなる(当てるべきREDOログを大量に持つことを許す、ということなので)、
というデメリットがある点は要注意ですが、
少なくとも、上のグラフでみたような事態になっているようであれば、
どう考えてもib_logfileを拡張すべきと言えるでしょう。
では。