この文章では、Linuxコマンド、sar, top, psを使って、一般的に負荷といわれるものの原因を切り分けることを目的とする。
「複数のタスクによるサーバリソースの奪い合いの結果に生じる待ち時間」を一言で表した言葉。OSのチューニングとは負荷の原因を知り、それを取り除くことにほかならない。
- ロードアベレージ（処理を実行したくても、実行できなくて待たされているプロセス（CPUの実行権限が与えられるのを待っている、またはディスクI/Oが完了するのを待っている）の数）を見る
- CPU, I/Oのいずれがボトルネックかを探る
- top, uptimeコマンドで見る
- ロードアベレージは負荷の指標であって、それだけでどこがボトルネックの原因か判断することはできない。
- ロードアベレージが低いのにスループットが上がらない場合はソフトウェアの設定、不具合、ネットワーク、リモートホストに原因があるかもしれない。
sar や vmstat で時間経過にともなうCPU使用率やI/O待ち率の推移が確認できる
- ユーザプログラム、システムプログラムのどちらがボトルネックかtop, sarで確認する（大抵の場合はユーザープログラム）
- psで見えるプロセスの状態やCPU使用時間を見ながら原因のプロセスを特定
- プロセスの特定からさらに詳細を詰める場合は、straceでトレースしたり、oprofileでプロファイリングをするなりしてボトルネック箇所を絞り込む（プログラムのどこ）
- プログラムからの入出力が多い
- スワップが発生してディスクアクセスが発生している
↑のふたつがほとんど
ロードアベレージが高く、かつsarの%iowaitが高い場合は負荷の原因はI/Oであるといえる。
特定のプロセスが極端にメモリを消費していないかをpsで確認できる
↓
プログラムの不具合でメモリを使いすぎている場合は、プログラムを改善する
or
搭載メモリが不足している場合はメモリ増設で対応する。増設できない場合は分散を検討する
キャッシュ（ページキャッシュ）に必要なメモリが不足している
- メモリ増設でキャッシュ領域を拡大させられる場合は、メモリを増設する
- メモリ増設で対応しきれない場合は、データの分散やキャッシュサーバの導入を検討する
- 大規模な科学計算を行うようなプログラム。処理速度がCPUの計算速度に依存しているため「CPUバウンドなプログラム」と呼ばれる。
- ディスクに保存された大量のデータから任意のドキュメントを探し出すプログラム。ディスクの読み出し速度に依存するため「I/Oバウンドなプログラム」と呼ばれる。
/var/log/sa に格納されており、ファイル名末の数字二桁が日付を指している。時間の範囲を指定することも可能。
sar -f /var/log/sa/sa04 -s 22:00:00 -e 23:00:00
1秒おきに3回調べる
sar 1 3
CPU使用率をみる
ロードアベレージをみる
ランキューに溜まっているプロセスの数、システム上のプロセスサイズも参照できる。
値の推移を時間とともに追える点が他のコマンドと違う。
メモリの利用状況を見る
- kbmemfree： 物理メモリの空き容量
- kbmemused: 使用中の物理メモリ
- memused: 物理メモリ使用率
- kbbuffers: カーネル内のバッファとして使用されている物理メモリの容量
- kbcached: カーネル内でキャッシュ（ページキャッシュ）用メモリとして使用されている物理メモリの容量
- kbswpfree: スワップ領域の空き容量
- kbswpused: 使用中のスワップ領域の容量
時間推移とともにメモリがどの程度どの用途に使われているかを把握できる。sar -Wと組み合わせるとスワップが発生したときにその時間帯のメモリ使用状況がどうであったかを知ることができる。
スワップの発生状況を確認。
- pswpin/s 1秒間にスワップインしているページ数
- pswpout/s 1秒間にスワップアウトしているページ数
スワップが発生するとサーバーのスループットは極端に落ちてしまう。メモリ不足でスワップが発生しているか否か疑わしいときはsar -Wでその時間にスワップが発生していたかどうかで確認できる。
マルチCPUで各CPUの状況を調べるとき。
- サーバ/インフラを支える技術
- 大規模サービス技術入門
- Linux PROGRAMMER'S TOOLBOX