サーバー危機的瀕死寸前マニュアル

サーバーが死にそうになっているときのマニュアルです。
サーバークラスタリングとかスケールアウトとかスケールアップとか考えた方がいい。クラウドフロント辺りのキャッシュサーバでもいいかも。
原因は?と聞かれますがたいていは「サーバースペックがショボいから」というのが大半。

急いでやるやつ

  1. rootでログイン
  2. 簡易的に状態をみる load average
  3. 目でだいたいの状態を把握する top
  4. HDDの容量 df

ブラウザーアクセスやSSHでログインして明らかに操作が遅延したり見た目で動きがもっさりしていたりする、あるいは監視のアラートメールが来たりしているピーク時に目視するのが目的のコマンドになります。

落ち着いてやるやつ

  1. procs memory swap io system cpu
  2. プロセスを確認する ps

rootでログイン


面倒なので全部が見れるrootでログインしておく。

簡易的に状態をみる load average


uptimeを実行。

# uptime
 11:55:42 up 236 days, 16:45,  1 user,  load average: 6.19, 4.81, 4.09

この例ではログインユーザーが1人でロードアベレージがかなりヤバイ感じになってます。健康的なロードアベレージは1.0以下という認識でよいと思います。(これも賛美両論ありますが。。)4.0~6.0になったらすでに危機的な状態です。
ロードアベレージは単に負荷を合理的に数値化したもので、その処理の待ち時間というか処理されないで溜まっているタスクの割合を数値化したものです。なので、ロードアベレージが高い状態のときは以下の状況が考えられます。たいていの場合複数の事象が原因になってます。または1つの事象が複数の事象に波及している感じになります。

  • CPUの使用率が原因の場合
  • メモリ使用量が原因の場合
  • ディスクI/Oが原因の場合
  • TCPコネクション数が原因の場合

目でだいたいの状態を把握する top


先のuptimeのコマンドをより詳細に直感的に且つリアルタイムで把握する場合はtopコマンドです。Windowsでいうところのタスクマネージャになります。

# top -M

top - 12:04:23 up 236 days, 16:54,  1 user,  load average: 6.19, 4.81, 4.09
Tasks:  82 total,   8 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 93.4%us,  6.2%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   3751244k total,  2432336k used,  1318908k free,    94296k buffers
Swap:        0k total,        0k used,        0k free,  1545864k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
29142 apache    16   0 37548  19m 4096 S 16.7  0.5   0:29.28 httpd
28773 apache    15   0 37516  19m 4116 S 14.4  0.5   0:05.51 httpd
27277 apache    16   0 46272  28m 4780 R 13.5  0.8   0:38.01 httpd
(以下、省略)

-Mオプションをつけてメモリの消費順にソートします。これで何のプロセスがメモリを消費しているのかわかる。

注目は、

  • load average: 6.19, 4.81, 4.09
  • Cpu(s): 93.4%us
  • Mem: 3751244k total, 2432336k used, 1318908k free, 94296k buffers

という感じです。
ロードアベレージは先の通り。
Cpuの使用率は90%なんてもう駄目レベル。これが持続的に一日とか続いていたらもう駄目。
メモリはちょっと計算しないといけないのですが、簡易的に考えて「メモリの空き容量 = 未割り当て容量(free) + ディスク同期にて解放可能な容量(ファイルページ≒バッファ&キャッシュ)」になるので、

FREE: 5391404k = 1318908k(free) + 94296k(buffers) + 1545864k(cached)

ってことになります。すなわち、5.14GB程度の空きのメモリがあることになります。まだメモリは余裕があるという感じになります。
バイト変換でキロバイト、メガバイト、ギガバイト、テラバイトへ変換

※スワップはメモリが豊富に共有できる現在なので通常使わないです。(少なくとも私は使わないです。)

また各プロセスのリアルタイムの値が出てくるのでそれを全体的に見てみます。

PID … プロセスID
USER … プロセスの実行ユーザ
PR … プロセスの静的優先度(値が低い方が優先度が高い)
NI … プロセスの相対優先度(0を基準とし、-20(優先度高) ~ 19(優先度低)で表している)
VIRT … プロセスの仮想メモリーサイズ(スワップアウトしたメモリー使用量を加えたメモリー容量)
RES … プロセスの使用しているメモリー容量(物理メモリー容量)
SHR … プロセスの使用している共有メモリー容量
S … プロセスの状態
%CPU … CPU使用率
%MEM … 物理メモリー使用率
TIME+ … プロセスの実行時間
COMMAND … プロセスで実行されているコマンド

WEBサーバーへのアクセスが多い場合はやたらとhttpdが出てくるしBatch処理でバックグラウンドで何かが走っている場合はそのプロセスが出てくると思います。Linuxのシステム自体を支えるプロセス以外で注目すべきは、httpd,postfix,mail,zabbix_agentd,mysqlなど後から追加したミドル・ウェアのプロセスになります。

HDDの容量


画像がアップできないとか何らかの動作ができない(のにエラーが起きない)とかの場合はHDDが100%になっている場合があります。

# df -h
Filesystem          サイズ  使用  残り 使用% マウント位置
/dev/sda1              20G   17G  1.8G  91% /
none                  1.8G     0  1.8G   0% /dev/shm

-hオプションをつけてGBで見るのが現代的です。(昔はMBやKBで見てました。)
このコマンドで「おお結構いっちゃてるじゃん。」ってことなったら、どの部分が多くHDDを使っているかを見ます。まずはroot以下から見てみます。

# du -sh /* | sort -nr

452K    /tmp
288M    /lib
90M     /etc
33M     /sbin
28M     /boot
28K     /taguchi.log
28K     /dev
16M     /root
16K     /lost+found
13G     /home ←ここが大きい。
12K     /opt
12K     /mnt
7.3M    /bin
4.0K    /srv
4.0K    /selinux
4.0K    /net
4.0K    /misc
4.0K    /media
3.6G    /proc
2.1G    /usr
1.4G    /var /home ←ここが大きい。

通常は/homeと/varなどが肥大化します。また/tmpがパーテーションで切り離されていて単独でいっぱいになっている場合も障害が生じたりするのにご注意。ここから先はさらに/homeに行って/home以下で大きなファイルサイズのものがないか順次調査してゆきます。
Webのサービスだと通常はログか画像かPDFかみたいな比較的決まりきったものがいっぱいになっているケースばかりです。

落ち着いてやるやつ

procs memory swap io system cpu

# 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      0 120744  53432 3075724    0    0     3    51    2    0  9  1 90  0  0
 1  0      0 119440  53432 3077016    0    0  1280     0 1225  413  1  0 98  0  1
 0  0      0 117180  53436 3078032    0    0  1028     0 1142  416 54  8 38  0  0
 0  0      0 117184  53436 3078168    0    0   128     0   81   55  0  0 100  0  0
 0  0      0 116284  53444 3079044    0    0   896   352  818  253  0  0 99  1  0
 0  0      0 116164  53444 3079180    0    0   128     0   95   58  0  0 100  0  0
item value
procs r – 実行待ちのプロセス数
b – I/O待ちのプロセス数
memory swpd – スワップの使用量
free – 空きメモリ容量
buff – バッファキャッシュの使用量
cache – ページキャッシュの使用量
swap si – スワップインした回数の秒間平均
so – スワップアウトした回数の秒間平均
io bi – HDDから読み込んだブロック数の秒間平均
bo – HDDへ書き込んだブロック数の秒間平均
system in – 1秒あたりの割り込み回数
cs – 1秒あたりのコンテキストスイッチの回数
cpu us – カーネル以外が使用したCPU使用率
sy – カーネルが使用したCPU使用率
id – アイドル状態の割合
wa – I/Oウェイトにかかった割合
st – Xenなどで、別のDOMが使用したCPU割合

注目すべきはprocsのrとbの値です。ここが0以外の値が入っているものが頻発している場合はI/Oの処理が手詰まりになっているということになります。この処理の遅れがロードアベレージの値になります。それらのプロセスがどれぐらいのメモリを使って、CPUをどれくらいつかっているかなどつぶさに見てゆくとよいです。

プロセスを確認する ps

psでやるとやたらとたくさんのプロセスが出てきちゃうのでgrepである程度絞って見たほうがいいです。topコマンドでだいたいの目安がついていると思うので。
「ps aux | grep [サービス名]」で各プロセスの細かいところ見ていきます。例えば、

# ps aux | grep zabbix
root      2006  0.0  0.0   6604   644 ?        S    Jan04   0:00 zabbix_agentd -c /etc/zabbix/zabbix_agentd.conf
root      2014  0.0  0.0   6604   680 ?        S    Jan04   2:47 zabbix_agentd: collector [idle 1 sec]
root      2015  0.0  0.0   6608   960 ?        S    Jan04   0:38 zabbix_agentd: listener #1 [waiting for connection]
root      2016  0.0  0.0   6608   960 ?        S    Jan04   0:42 zabbix_agentd: listener #2 [waiting for connection]
root      2017  0.0  0.0   6608   960 ?        S    Jan04   0:45 zabbix_agentd: listener #3 [waiting for connection]
root      2018  0.0  0.0   6896   840 ?        S    Jan04   0:13 zabbix_agentd: active checks #1 [idle 1 sec]
root     27500  0.0  0.0   5136   772 pts/1    R+   18:54   0:00 grep zabbix

やたらとたくさん出てきたりしたら、もうリクエストの処理で手一杯みたいな感じだったり。なんのコマンドが、何にCPUを費やしているのかというのが詳細にわかります。どうでもいいcronが1分おきに起動していたり、いろいろあるので細かく見ていくとよいです。

ここまででだいたい原因は特定できるはず。


Linuxパフォーマンス調査などで使うコマンドメモ
LinuxのI/OやCPUの負荷とロードアベレージの関係を詳しく見てみる
psコマンドで表示される内容について調べた

Last update: 2018.08.29 (水)