過去のブログを掘り起こして、当時分からずじまいだったことをAIニイの力を借りて解決していくシリーズの3回目です。
第3回目は、2012年3月3日の内容です。懐かしいね。
内容をまとめると、WordPressの挙動がもっさりしてる感じがしていたので色々調べてたことの一つに「phpMyAdminでMySQLのオーバーヘッド140キロバイト」というのがあって、最適化したらそのもっさり感がかなり軽減した！っていう内容。
感動してたわりには
「すごーい。」
の一言で終わっていたのだった。
なんで140キロバイトで効いたのかは書いていなかったし、どの程度早くなったのかもわからないし。
理由についても当時はよくわかってなかったんだと思う。というかわかってたら書いてるはずなのだ。
オーバーヘッドとは
MySQLはデータを削除したり更新したりしても、その領域をすぐに解放しなくて、ここは使わなくなったぜ。という印をつけるだけで、実際のディスク上の領域はそのまま残る。これが断片化した領域のオーバーヘッドというやつだ。OPTIMEZE TABLE を実行すると断片化した領域を整理してテーブルを綺麗に詰め直してくれる。
なんで140KBで効いたのか
ここが謎の核心で、140キロバイトというのは確かに小さい。ただサイズの問題というより断片化の問題だったわけで、140KBというのはあくまで無駄な領域のサイズで、断片化したページ数はその何倍にもなっていた可能性があったのかもしれん。
当時のVPSというのはメモリがかなり限られた環境で、512MBとか1GBとかそのくらいだった。MySQLはクエリの結果をメモリにキャッシュして高速化しようとするんですが、断片化したテーブルはそのキャッシュ効率が悪くなるらしい。メモリがカツカツなVPSではその影響がもろに出やすかった、みたいな。
ちょこっと整理したら部屋が劇的にすっきりすることがある。それだ！
断片化の最適化で得られること
大きく3つあって。
- クエリーが速くなる
- メモリのキャッシュ効率がよくなる
- ディスクの無駄遣いが減る
断片化したテーブルはデータが物理的にバラバラに配置されているので、MySQLがデータを読みに行くとき、あちこち飛び回って拾ってくることになる。整理されるとデータが連続して並ぶので読み込みが一直線になる。140KBで効いた謎の答えはたぶんキャッシュ効率のところだと思います。
MyISAMは断片化が起きやすかったっぽいけれど、当時もすでにInnoDBだったような。どっちだったんだろうか。
当時Mysql5.5 だった場合 innodb_file_per_table がDisabledだったかもしれんし、確認しようがないけど、そうなのかもしれない。
何年か前からはプラグインを使って定期的にOPTIMIZEをかけてるけれども、それ以前にサーバーを変更してめちゃはやになってる影響でそんな体感できるようなことは起きてないなあ
最近のWordPressでもっさりの原因はDBの断片化よりも、プラグインの多さやキャッシュ設定の方が大きいケースが多いのだろうね。