こんにちは、さくらインターネットクラウドチームの大喜多です。

システムを運用していく上で、ボトルネックを把握し、有効な対策をとれるようにすることは非常に重要です。このことはクラウド時代になっても変わりません。むしろ、インフラが抽象化されたクラウド上でシステムを運用する際にこそ、システムパフォーマンス低下の切り分けを適切に行うための知識はより重要になってくるのではないでしょうか。本記事ではLinuxにおける主要なパフォーマンスモニタの使い方についてご紹介致します。

CPUの負荷を把握する
ストレージの負荷を把握する
ネットワークの流量を把握する
さくらのクラウドで取り得る対策
まとめ

CPUの負荷を把握する

アプリケーションのレスポンスが期待通りでない・サーバの動作が重い等の現象を感じたら、まずはじめにtopコマンドでCPU負荷の高いプロセスを調べてみましょう。

[root@test ~]# top
top - 18:04:25 up 19 days, 22:51,  1 user,  load average: 0.05, 0.02, 0.00
Tasks: 121 total,   1 running, 120 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.0%us,  1.0%sy,  0.0%ni, 93.6%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1020212k total,   830908k used,   189304k free,    32768k buffers
Swap:  4194300k total,   270960k used,  3923340k free,   360256k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1391 mysql     20   0 1321m 304m 4884 S  0.3 30.6  75:05.25 mysqld
 1587 zabbix    20   0  177m  14m  12m S  0.3  1.5  28:43.99 zabbix_server
    1 root      20   0 19232 1020  820 S  0.0  0.1   0:08.64 init

左から8番目（SHRの右）の「S」のフィールド(プロセス状態)を確認します。
上記の例は全てS（スリープ）状態となっています。
S以外にも下記の通りR、Dという状態があります。

プロセス状態	意味
R	実行(可能)状態：CPUリソースを消費している 9番目のフィールド(CPU使用率)を確認し、継続的に使用率が高い場合、CPUがボトルネックになっている可能性がある
D	ストレージのIO完了待ちが多発しているストレージがボトルネックになっている可能性がある
S	スリープ状態またはネットワークを介したデータ送受信等のイベント待ち CPUには余裕があるが通信が遅くなっている場合、ネットワークがボトルネックになっている可能性がある

CPU、もしくはストレージがボトルネックになっている場合、vmstatコマンドを用いて切り分けを行います。

[root@test ~]# vmstat 1 
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 271328 110320  59792 392132    0    0     1   165    0    5  1  0 88 11  0
 0  0 271328 110304  59792 392132    0    0     0    16  101  175  1  0 99  0  0
 0  0 271328 110304  59792 392132    0    0     0   436  154  276  0  0 98  2  0

右から3番目のフィールド(id)がCPUの空き具合(%)を、右から2番目のフィールド(wa)がストレージのIO完了待ちの割合(%)を示しています。このケースではCPUの使用率は高くありませんが、若干IO完了待ちが発生しているタイミングがあるようです。

vmstatコマンドでは、マルチコアCPUのサーバの場合、全コアの利用率を平均した値が表示されます。mpstatコマンドを使用することで、コアごとの使用率（%usr）が確認できます。マルチコアCPUのサーバでありながら特定のコアに負荷が集中している場合、アプリケーションやミドルウェアの見直しが必要になります。またコア全般的に使用率が高い場合、CPUコア数を増やすことで改善できる可能性があります。

下記例はCPU4コアの場合。
一番右の%idleと%iowaitがCPUの空き率となります。
%usrがCPUの使用率となりますが、%idleの代わりに%iowait（io処理待ち）が上がっています。
下記例では各CPUの使用率は「0」となっていますが、実際にCPUで計算が行われるタイミングでは、この部分の数値が上がります。

[root@test ~]# mpstat -P ALL 1
12:23:45     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest   %idle
12:23:46     all    0.00    0.00    0.00    7.02    0.00    0.00    0.00    0.00   92.98
12:23:46       0    0.00    0.00    0.00   28.00    0.00    0.00    0.00    0.00   72.00
12:23:46       1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
12:23:46       2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
12:23:46       3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

freeコマンドを使用することで、現在のメモリの使用率（used）を把握することができます。以下の例では「-m」オプションを付けてMB単位で表示させています。

 
[root@test ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           996        888        107         10         58        383
-/+ buffers/cache:        447        549
Swap:         4095        264       3831

1GBのメモリに対して空きメモリ（free）は107MBですから、メモリの使用率は高い状態にあるといえます。ストレージのキャッシュに使用されている空間(buffersおよびcached)の両方を差し引くと、プロセスに割り当てられている実際の消費メモリがわかります。また、併せてSwap:行の値を確認しましょう。Swapの利用量が高くなる原因として、「休眠プロセスのページが実メモリからSwapに追い出される」場合と「実稼働プロセスの利用領域として使用されている」場合がありますが、後者の場合システムのパフォーマンス劣化につながりますので、注意が必要です。

ストレージの負荷を把握する

ストレージのアクセス状況を把握するにはiostatコマンドを用います。以下のように実行すると、1秒間隔でブロックデバイス毎の負荷状況が表示されます。

[root@test ~]# iostat -dmxt 1 
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
vda               0.02    32.17    0.09    9.71     0.00     0.16    34.03     0.02    2.51   0.88   0.86

r/sは秒間あたりの読み込み、w/sは秒間あたりの書き込みIO数(IOPS)を示しています。

ネットワークの流量を把握する

ネットワークの流量をリアルタイム把握するにはvnstatコマンドを用います。(インストールされていない場合はyumコマンドでインストールします)

rxが受信のネットワーク流量で、txが送信のネットワーク流量です。

[root@test ~]# vnstat -i eth0 -l
Monitoring eth0...    (press CTRL-C to stop)

   rx:        8 kbit/s    13 p/s          tx:        8 kbit/s    11 p/s

さくらのクラウドで取り得る対策

システムのボトルネックが生じている場合、さくらのクラウドであれば以下の対策が可能です。

CPU負荷が高い場合

マルチコアを生かせるアプリケーションにおいて各コアの負荷が満遍なく高い場合、コア数を増やすことで改善できる可能性があります。さくらのクラウドではサーバ作成後もコア数の変更ができます。また、アプリケーションの特性上マルチコアを生かせない場合は、ロードバランサを用いて複数のサーバに負荷分散することで改善できる可能性があります。

メモリの使用率が高い場合

メモリを増やすことで改善できる可能性があります。さくらのクラウドではサーバ作成後もメモリ容量の変更ができます。

ストレージアクセスの負荷が高い場合

さくらのクラウドの仮想ディスクには「標準プラン」と「SSDプラン」があります。「SSDプラン」の方がより高速なストレージになっていますので、標準プランを利用されている場合はSSDプランに変更することで改善できる可能性があります。また、容量毎にIOPSが異なりますので、よくある質問(技術的な事項)のディスクへのIOPS(1秒あたりのI/O数)やデータ転送帯域などの制限はありますか?をご確認ください。

また、さくらのクラウドはブリッジ接続を使用することでさくらの専用サーバと接続することができます。データベースのように高IOPSが求められるアプリケーションは専用サーバを利用するということも可能です。

ネットワークの流量が多い場合

インターネット向けのネットワーク流量が多くシステムのパフォーマンスに影響が出ている場合、共用セグメントからルータ＋スイッチへの接続変更、ルータ＋スイッチの帯域変更で改善できる可能性があります。

まとめ

このように「さくらのクラウド」であれば、動的なCPUコア数／メモリ容量の変更や、専用サーバとの併用に対応していますので、システムの負荷が高くなった場合でも迅速に対処することが可能です。また、スペックの見直しも重要ですが、アプリケーションやミドルウェアに無駄が生じていないか、今一度確認することで、コンピューティングリソースを有効活用することができます。

また、さくらのクラウドでは、コントロールパネル上でアクティビティグラフを参照する機能もありますので、併せてご活用ください。