はじめに
学習意欲を奮い立たせるため、blog更新を再開しようと思います。
とりあえずアウトプットすることが大切ということで、障害対応時の調査手順などを整理してみたいと思います。
そのため、目新しいものは何一つありませんこと、ご了承下さい。mm
■環境
基本的に、私の検証環境(amzn linux)で試したものを記載しています。
[ec2-user@mitzi_dev ~]$ uname -r 3.14.33-26.47.amzn1.x86_64
01. 負荷系(CPU, load avg)
01-1. load avg (処理待ちのプロセス平均数)
[ec2-user@mitzi_dev ~]$ cat /proc/loadavg 0.00 0.01 0.05 1/111 10281 [ec2-user@mitzi_dev ~]$ w 21:27:24 up 375 days, 4:40, 1 user, load average: 0.00, 0.01, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT ec2-user pts/0 xxx.xxx.xxx.xxx 20:54 4.00s 0.01s 0.00s w [ec2-user@mitzi_dev ~]$ top d 2 top - 21:42:08 up 375 days, 4:55, 1 user, load average: 0.00, 0.01, 0.05 (省略) など
■備考
load avgの適正値としてCPUコア数で割って1以下が良いという考え方があるようですが、状況によって異なるとの話もあるようです。ちなみにコア数の調べ方は下記
[ec2-user@mitzi_dev ~]$ nproc 1 [ec2-user@mitzi_dev ~]$ cat /proc/cpuinfo | grep -c processor 1
01-2. CPU Utilization
▽CPU使用率の確認 [ec2-user@mitzi_dev ~]$ top d 2 top - 21:42:08 up 375 days, 4:55, 1 user, load average: 0.00, 0.01, 0.05 Tasks: 92 total, 1 running, 91 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st (省略) ※ デフォルトCPU使用率で降順となっている → Cpu(s)欄より %us: ユーザプロセス、 %sy: システムプロセスなど、負荷の内訳が表示されている。 → vmstat の CPU欄でも同様 ▽CPU使用率の高いプロセスの確認 → CPU使用率、MEM使用率順にソートして、上位5つを表示している [ec2-user@mitzi_dev ~]$ ps aux | sort -rk 3,4 | head -n 5 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND apache 7255 0.0 9.5 489884 97400 ? S 03:15 0:00 /usr/sbin/httpd apache 7257 0.0 9.0 484112 91928 ? S 03:15 0:00 /usr/sbin/httpd apache 7625 0.0 7.4 460432 75712 ? S 05:17 0:00 /usr/sbin/httpd apache 7624 0.0 7.4 460432 75728 ? S 05:17 0:00 /usr/sbin/httpd
02. メモリ関連(メモリ不足、swap、buffer/cache)
02-1. メモリ不足
・基本
[ec2-user@mitzi_dev ~]$ free -m
total used free shared buffers cached
Mem: 996 852 143 0 119 124
-/+ buffers/cache: 608 387
Swap: 0 0 0
→ まずfree(空きメモリ)の値を見るが、「buffers/cache」(ページキャッシュ)のfreeも物理メモリ量として換算出来るためそちらも考慮した上、メモリ利用状況を判断する必要がある。
※ 話が飛ぶが、Nagiosの標準plug-inではMemのfree値を見て判定しているため、正確とは言えない。
→ 例ではswap領域を定義していないため値が出ていませんが、swapのfreeが少なくなると
'OOM Killer' や 'Out Of Memory' が発生し、メモリを確保するためwebサーバなどのプロセスが強制終了される恐れがあるため注意が必要です。
swapの空き容量を監視することが大事と思われます。
$ topコマンド
(shift + m)でメモリ使用率での降順となる
・メモリ使用率 = RSS(Resident Set Size)の多いプロセスをピックアップ
[ec2-user@mitzi_dev ~]$ ps aux --sort -rss | head -n 5
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
apache 7255 0.0 9.5 489884 97400 ? S 03:15 0:00 /usr/sbin/httpd
apache 7257 0.0 9.0 484112 91928 ? S 03:15 0:00 /usr/sbin/httpd
apache 7393 0.0 7.4 460448 75828 ? S 03:49 0:00 /usr/sbin/httpd
apache 7625 0.0 7.4 460432 75748 ? S 05:17 0:00 /usr/sbin/httpd
[ec2-user@mitzi_dev ~]$ cat /proc/meminfo
(省略)
02-2. SWAP消費プロセスの確認
・swap消費量の多いプロセス(PID)の上位5つを表示 ※ `/proc/[PID]/status` となっており、ここでは該当プロセスのPIDを特定している。 ※ 私の環境ではswap領域を定義していないため、下記のような表示となっています。 [ec2-user@mitzi_dev ~]$ grep VmSwap /proc/*/status | sort -k 2 -r | head -n 5 /proc/self/status:VmSwap: 0 kB /proc/7642/status:VmSwap: 0 kB /proc/7625/status:VmSwap: 0 kB /proc/7624/status:VmSwap: 0 kB /proc/7623/status:VmSwap: 0 kB
03. ディスク関連(容量不足、inode枯渇)
03-1. 容量不足
・状態確認 [ec2-user@mitzi_dev ~]$ date; df -h 2017年 6月 13日 火曜日 22:18:47 JST ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/xvda1 20G 4.7G 15G 24% / devtmpfs 491M 56K 491M 1% /dev tmpfs 499M 0 499M 0% /dev/shm ・主な要因調査 (例: ルートディスク配下が不足していた場合) [ec2-user@mitzi_dev ~]$ sudo du -sh /* | grep G | sort -nr 2.5G /usr 1.2G /home ※この方法ですとアクセス出来ないディレクトリ情報が出ます。もっとスマートな調査方法調べておきます。。 ・上記の結果を元に/usr配下を検索(これを繰り返す) [ec2-user@mitzi_dev ~]$ sudo du -sh /usr/* | grep G | sort -nr | head -n 5 1.1G /usr/local ▽その他 ・ファイル単位でディスク使用量の高いものをピックアップ [ec2-user@mitzi_dev ~]$ sudo du -h /* | sort -nr | head -n 5 1020K /usr/share/zabbix/locale/el/LC_MESSAGES 1020K /usr/share/pki/ca-trust-source 1020K /usr/share/gettext/intl 1020K /usr/local/src/ffmpeg/libswscale/x86 1020K /usr/lib64/python2.6/site-packages/Crypto/SelfTest
03-2. inode枯渇
■ inodeとは
- IT用語辞典より
http://e-words.jp/w/inode.html
inodeとは、UNIX系OSの一部のファイルシステムで用いられる、ファイルやディレクトリについての情報を記録した管理データのこと。
inodeは一つ一つのファイルやディレクトリごとに作成され、各inodeには装置内で固有(一意)の整数値(inode番号)が割り当てられる。ファイルやディレクトリはシステム上ではこのinode番号で識別される。
よくある例
ディスク容量に余裕があるのに、ファイル書き込みができなくなった。
→ inode枯渇が起きている可能性あり
inode使用状況確認
[ec2-user@mitzi_dev ~]$ df -i ファイルシス Iノード I使用 I残り I使用% マウント位置 /dev/xvda1 1310720 182339 1128381 14% / devtmpfs 125487 427 125060 1% /dev tmpfs 127523 1 127522 1% /dev/shm
▽各項目
| 項目 | 説明 |
|---|---|
| Iノード | 該当deviceで利用出来るinodeの限界値 |
| I使用 | inode使用量 |
| I残り | inode空き容量 |
| I使用% | inode使用率 |
※私の環境では、何故dfコマンドの結果が日本語表記なのか。。
■対処
- 不要なファイルを削除する
- inodeの上限数を増やす
・巻き戻せるようにコピーを取っておきましょう $ cp -p /etc/fstab /etc/fstab.`date +%Y%m%d` $ vi /etc/fstab tmpfs /dev/shm tmpfs defaults 0 0 ↓ tmpfs /dev/shm tmpfs defaults,nr_inodes=256k 0 0 ※ EBSなどマウントしているディスクだともっと楽そう ・mountし直して反映 $ umount /dev/shm $ mount /dev/shm 注: この手法の場合、ディスクの中身が真っさらになるので注意
04. ディスクI/O
04-1. ディスクI/Oボトルネックの測定
・vmstatより [ec2-user@mitzi_dev ~]$ vmstat 1 5 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 108196 149836 15396 0 0 0 2 1 1 0 0 100 0 0 0 0 0 108220 149836 15380 0 0 0 0 40 65 0 0 100 0 0 → bi/boの値を見ます。 bi: Blocks received from a block device (blocks/s) bo: Blocks sent to a block device (blocks/s)。
05. ネットワーク関連
05-1. TCPコネクション数の総数
[ec2-user@mitzi_dev ~]$ netstat -an | wc -l 120
05-2. 経路の問題確認
・経路中に応答遅延が発生していないか確認 [ec2-user@mitzi_dev ~]$ traceroute example.com traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets 1 ec2-175-41-192-244.ap-northeast-1.compute.amazonaws.com (175.41.192.244) 19.357 ms ec2-175-41-192-242.ap-northeast-1.compute.amazonaws.com (175.41.192.242) 19.850 ms ec2-175-41-192-240.ap-northeast-1.compute.amazonaws.com (175.41.192.240) 20.097 ms 2 100.64.2.10 (100.64.2.10) 11.821 ms 100.64.0.12 (100.64.0.12) 19.953 ms 100.64.3.72 (100.64.3.72) 22.181 ms 3 100.64.0.197 (100.64.0.197) 607.232 ms 100.64.3.133 (100.64.3.133) 607.234 ms 100.64.2.65 (100.64.2.65) 718.342 ms 4 100.64.17.65 (100.64.17.65) 0.413 ms 100.64.17.161 (100.64.17.161) 0.517 ms 100.64.16.99 (100.64.16.99) 0.408 ms 5 27.0.0.159 (27.0.0.159) 0.684 ms (省略)
ほぼ箇条書きになってしまいましたが、自身のメモ用の面が大きいためご容赦下さい。
