/dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど)

前エントリーから一部の内容を分離して追加記事にしてみました。以下実施したメモリ増設の効果について。

ここ数ヶ月、自宅サーバの負荷がだんだんと上昇してきていて、そろそろ1台で高速にさばききる限界に近づいてきた感があったり。ここ数週間のロードアベレージはこんな感じ。グラフは× 100 の値になってます。CPU のコアが2個なんで、200 までは OK ということでまだ処理しきれているわけではあります。ちなみに mrtg グラフは瞬間値を示しているわけではなく平均値なので瞬間的にはもっと負荷が高いときとかあります。

でも月次処理が走るともっさり感満点。

la-week.png
※緑:1分平均 / 青:15分平均

実は CPU の処理速度が追いついていないと言うより I/O 周りがボトルネックになっています。

disk_io-week.png
※緑:読取ブロック数 / 青:書込ブロック数

- スポンサーリンク -

ということで、メモリを2GBプラスして、合計 4GB にして参照系のデータ周りを /dev/shm に移動したらこうなりました。予想通り、ロードアベレージは半減してイイ感じに!
disk I/O のグラフも思惑通りに読込 I/O が激減してこれまたイイ感じに!
※グラフ右端の土曜日のところからです。

la-week.png
※緑:1分平均 / 青:15分平均

disk_io-week.png
※緑:読取ブロック数 / 青:書込ブロック数

とまぁ当然の結果ではありますが参照系 DB をメモリ上(ここでは /dev/shm を利用してます)へ持って行くと、I/O が改善されてかなりの負荷低減を実現することができます。以前、qmail の配信能力を極限まで引き出す方法(ログ関連)って記事を書いたときは、書込 I/O 改善で /dev/shm を使う例を書きました。

何だかんだ言って disk はメモリに比べて数百倍以上遅い媒体なので、消えても問題がないもしくは即座に同じデータが生成(復旧)できるようなデータは /dev/shm を使うとかなりイイ感じ。

__追記__
ちなみに、今回実施した参照系DBとは mysql じゃなくって独自のインデックスデータだったりするので mysql とかだと別解とかあると思います。

- スポンサーリンク -