サービスの安定化を目指す（1）
使っているサーバの性能を把握する
単にサーバと言っても、メモリやCPU、ディスクどれを取っても、それぞれ顔が違います。ウェブに向いたものや、DBに向いたもの、それぞれ違いがあり、どうやって性能を引き出すかは非常に面白いテーマでしょう。
ただし、引き出す以前に限界を知らないということがよくあるような気が致します。
100の力があって、100引き出したいのに、限界を知らないので、50しか使っていなかったり、もしくは200を引き出そうとしていたり。
そういった意味で、今回は安定化に向けた記事の第一弾として、「限界」ということについて自分になりに書いてみます。この分野は何度やってもまだまだ勉強足りないので、自分への戒めも含めて。
限界を知る
サーバというのは極めて素直なもので、120%の力を出すことはできません。CPUバウンドなサービスにせよ、I/Oバウンドなサービスにせよ、スペック以上のことを求めれば、絶対に負荷は高まり、ロードアベレージもどんどん高くなっていくでしょう。
たとえば、apacheをpreforkで走らせているなら、以下のコマンドでプロセス数を把握してみましょう。
$ ps aux | grep httpd | wc -l
60
この場合、httpdが60プロセス現時点で立ち上がっていることになります。もちろん、busyかidleかはここからは分かりませんが、プロセス数の把握は非常に重要です。
現時点で既にサービスが稼働しているなら、topコマンドやpsコマンドを使って、1プロセス当たりのメモリを大体算出してみる。
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
333 httpuser 15 0 179m 18m 400 S 0.0 0.4 12:12.12 httpd
444 mysqluser 15 0 44012 34m 2448 R 15.0 0.3 12:12.12 mysqld$ ps auxw | egrep '(STAT|httpd)'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
httpuser 333 0.1 0.1 18000 10000 ? S 12:12 0:00 /usr/local/apache2/bin/httpd -k start
httpuser 334 0.1 0.1 18000 13712 ? S 12:12 0:01 /usr/local/apache2/bin/httpd -k startもしくは
$ ps alx | head -1 && ps alx | grep httpd
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
1 1 333 5939 15 0 18000 10000 - S ? 0:01 /usr/local/apache2/bin/httpd -k start
値は改変してますが、topコマンド(上記はCent5の例)なら、「RES - SHR」で1プロセスあたりのメモリ使用量を、psコマンドならRSSの値を参考に。
共有メモリの分を引くかどうかはまぁ好みで。
(18000 - 400 ) = 17600 で、17.6MB使ってることが分かる。あとは、プロセス数をかけて、現時点で搭載メモリをオーバーしてないか確認する。
搭載メモリの確認は、「$ free」や「$ cat /proc/meminfo」でいける。
上限を設ける
んで、ここまで確認したら、上限を設定しておくのがよいでしょう。
24時間フル稼働してるのに、上記のような確認をピークタイム以外でやっても、フルパワーのときの状態を測れません。
だから、フルパワーになっても大丈夫なように、リミットを設けておく。それがPreforkのチューニングです。設定例は、以下のような感じですが、詳しくは「apache（prefork）のチューニングについて」を読んでください。
StartServers 100
MinSpareServers 100
MaxSpareServers 100
MaxClients 100
MaxRequestsPerChild 1000
こうしておくことで、プロセスは100前後を常に推移することになります。上述の1プロセス当たりから、8,9割ぐらいのメモリを割り当てて、事前に立ち上げておくことで対策ができるでしょう。
逆にこのように上限を設けても捌ききれない、つまり常にbusyなプロセスが100を越えている場合は、サーバの能力を超えているので、スケールアウトするかスケールアップ（メモリを積んでプロセスを増やす）のがよいでしょう。
何よりも大事なのは、一台でこれぐらい捌くことができ、現在の構成ではもう限界ですと主張しやすい論拠ができることです（※もちろん、他の設定も見ていく必要はありますが）。
今まではapacheの例を引き合いに出し、色々述べてきましたが、他のミドルウェアでも同様です。「上限をしっかりと定め、能力以上のことはさせない」。この点を押さえておくことが非常に重要になります。
終わりに
今回は「限界」ということについて書いてみました。能力の限界はスケールアウトまたはスケールアップのスタートでもあり、分散環境の始まりでもあります。
ただし、そこに辿り着く前にちゃんと一台の能力を把握しておく。その第一歩としてプロセスという点からサーバについて見てみました。
次回はまた違った視点で能力についてみていければと思います。
