Muninで監視用サーバを構築する１でとあるWebサービスの監視をはじめた。

今の所、このサーバでは問題ない。


問題ない内に問題になりそうな箇所は潰しておけ

ということで、


そもそも各グラフが何を表しているのか？が明確でないのが問題なので、


orelly_system_p

O'Reilly Japan - 詳解 システム・パフォーマンス

ハードディスクが壊れる日は突然やってくる


システム・パフォーマンスを片手に各項目について調べてみることにしようかと。

あくまで勉強用のメモみたいなものなので間違いがあるかもしれないことを前提にしてください。



システム・パフォーマンスの本を読むと、

Webアプリが重くなった時はアプリケーション → CPU → メモリの順に疑えというけれど、

アプリケーションは監視対象にないからスルーするとして、

CPUがボトルネックになったことはあまりないので、

メモリから見ていくことにする。



munin_memory


このグラフに触れる前にWebサービスが動いているサーバにリモートアクセスして、

バッファキャッシュやページキャッシュを含めたフリーメモリを返すfreeコマンドを実行してみると、


$ free
              total        used        free      shared  buff/cache   available
Mem:        8175328      839240     6025992       95084     1310096     6947368
Swap:       8385532           0     8385532

こんな感じ。

明らかにサーバ側の方がオーバースペックですな。


Memはメモリでusedが使用しているメモリ

Swapとはメモリの使用量が限界を越えた時にディスク上にメモリの様に振る舞うスワップファイルを作成して、使用しているメモリをディスクに移行した時のディスク上の容量だと解釈している


上のグラフに戻って、appsというのは、メモリのused(使用量)の値という事で良さそうだ。


page_tablesだけど、

ページというのはOSとCPUが使うメモリの単位で、何かを実行する度にプロセスが生成され、そのプロセスに対してOSが使いたい時にアクセスできるようにアドレスを持つ。

page_tablesにはそれらのアドレスをマッピングしたものをメモリに格納している。


swap_cacheと後の項目のswapはとばして、

次のslab_cacheを見ることにする。


slabというのは、カーネルスラブアロケータというもので、

slab_cacheとうのはカーネルというOSの中核が利用するキャッシュらしい。


そもそもさっきから挙がっているキャッシュって何なの？ということで読んでみると、

限定された量のデータを重複して格納したりバッファリングしたりすることができる高速記憶領域を指す。


要は、CPUが一度実行した結果をキャッシュにして残しておき、

同じ処理を実行しようとした時、残しておいた処理の結果であるキャッシュを読めば、

余計なリソースを使わず、マシンを高速化できるようになる。


バッファは一時データのために使われるメモリ領域。

例えばテキストファイルを開いた時、読み込んだファイルのデータはメモリ上に用意されたバッファに置かれる。

表示されているテキストはファイルではなくバッファにあるデータを表示していて、これを一時データと呼ぶと個人的に解釈している。


unusedはその名の通り、未使用のメモリの量

vmalloc_usedはOSの深いところに入っていくみたいなので、今は触れないでおく。


committed 全プロセスによって確保された仮想メモリの総容量

mapped ページテーブルに登録されている物理メモリの総容量


最後にactiveだけど、

activeはメモリ上にあるページで最近アクセスされたものの総容量で、

inactiveは最近アクセスされていないものの総容量。

メモリが不足しはじめたら、inactiveにあるページから解放される。


これらを踏まえた上で、


munin_memory


改めてこのグラフを見てみるけれども、

やっぱりオーバースペックだ。