やったこと

サーバ/インフラを支える技術

4章読了
5章途中まで

学んだこと

sar ( System Activity Reporter )

CPU負荷、およびI/O待ち率を表示するコマンド。

■%userの値が高い

ユーザが実行したプログラムが、CPUを大量に使用していることを示す。

■%system の値が高い

以下を示す。

大量のプロセス/スレッドを動作させている
システムコールの呼び出し頻度が高い

■%iowait の値が高い

I/O処理完了の待ち時間が長いことを示す。

マルチコア環境だと、特定のCPUに負荷が偏っている可能性がある。
sar -P ALL オプションにて、各CPUの負荷を見比べることも大事。

ロードアベレージ

システム全体の負荷を表す指標。
CPU使用率やI/O待ち率は、CPU個別の負荷を表す指標。
ロードアベレージにて、システム負荷の有無を把握する。
負荷があれば、CPU使用率やI/O待ち率から、負荷の詳細を追っていく。

カーネルにとって、プロセスとスレッドは大差ない。
全く同じロジックでスケジューリングされる。

スレッドは、LWP ( Light Weight Process )とも呼ばれる。（ ps -L コマンドにて、 LWPという項目が表示される）

ps auxw 要点

■VSZとRSS

VSZは仮想メモリサイズ、RSS は物理メモリサイズを表す。
RSSが大量に消費されている場合、スワップが発生している可能性がある。

■TIME

プロセスがCPUを使用した時間。
CPU負荷が高い場合、TIMEの値を確認することで、どのプロセスがCPUを占有しているのか判断できる。

無限に足し算を行うようなループだと、TIMEの値がどんどん増える
ユーザの入力待ち状態だと、TIMEの値は変化しない

Linuxのページキャッシュ

Linux は、空きメモリを、可能な限りページキャッシュに回そうとする。
頻繁にReadするデータを事前に読み込むことで、意図的にページキャッシュへ回すことができる。

RDBだと、起動直後はページキャッシュが空の状態。
この状態では、ディスクまでI/Oが発生するため、起動直後はパフォーマンスが低い。

まとめ

■ロードアベレージから、システム全体の負荷の有無を読み取る

top コマンドにて確認。

■CPUに負荷をかけているのはユーザとシステムのどちらか確認する

sar コマンドにて確認。

%user の値は、ユーザがCPUに負荷をかけている割合を示す
%system の値は、システムがCPUに負荷をかけている割合を示す

（マルチコア環境では sar -P ALL にて、CPU別の負荷を確認できる）

■I/O待ち時間の有無を確認する

sar コマンドにて確認。

%iowait の値は、IOによる待ち時間を示す

■システムに負荷をかけているプロセスを特定する

ps auxw コマンドにて確認。

RSSの値が大きい場合、スワップが発生している可能性がある
TIMEの値が大きい場合、対称プロセスがCPUを占有している可能性がある

■スワップ発生状況を見る

sar -W コマンドにて確認。

■I/Oのデータ量を確認する

vmstat コマンドにて確認。

biがディスクからの読み出し、boがディスクへの書き込みを示す

考えられそうな対策

■CPU負荷が高い

スケールアウトする
アルゴリズムを見直す

■ディスクIOが高い

メモリを増設する（≒ページキャッシュの増設）
キャッシュソリューションを導入する
- MemcachedやRedis

Webサーバのチューニング

方針

より多くのクライアントを、一度に捌くことができること。
一クライアントに割り当てるコンピューティングリソースを抑えること。

マルチプロセスかマルチスレッドか

Webサーバのメモリ上限や、アプリケーションにおけるコンテキストスイッチの回数を参考に、マルチプロセスかマルチスレッドかを選択する。

クライアント数の上限値

Apacheであれば、以下の二つのパラメータが該当。

ServerLimit
- プロセス数の上限
MaxClient
- 同時接続可能なクライアント数の上限

マルチプロセス環境であれば、両者はほぼ同義。
マルチスレッド環境であれば、以下の通り。

ServerLimit * ThreadLimit = MaxClient

コンテキストスイッチ

プロセスを切り替える処理のこと。
コンテキストスイッチが発生しないマルチスレッドは、高速な処理が可能。

マルチスレッドが効果を発揮する場面

大量のコンテキストスイッチが発生するような処理
メモリ消費を抑えたい場合（メモリ容量が小さいなどの理由）

Copy on Write

メモリの更新処理が走るときに初めて、子プロセスが親プロセスから値をコピーするという挙動。
Auroraのクローンと、考え方は同じ。

Apache MaxRequestPerChild ディレクティブ

子プロセスが捌ける、最大リクエスト数を設定する項目。
最大リクエスト分を捌ききると、子プロセスを終了させ、新規に子プロセスを立ち上げる。

新規に子プロセスを立ち上げる（≒親プロセスからforkする）ことで、メモリ空間を完全に共有した状態に戻すことができる。
つまり、メモリを節約できる。

サービスの稼働監視

稼働監視は、以下の三つに分類される。

ホストやサービスの死活監視
- そもそもサービスが提供できているのかを監視する
ホストやサービスの負荷監視
- 死活監視では検出できない、「一応使えるけど何か遅い」を検出する
一定期間（1か月や一年）の稼働率計測
- 中長期的に監視を続けることで、「不安定なサーバの検出」や「不安定なシステム構成のあぶり出し」、つまり継続的な改善が期待できる

サーバリソースのモニタリング

サーバリソースの変動を観察する活動。
変動を継続的に記録し、視覚化によって傾向や変動を把握しやすることで、トラブル発生時の原因究明に役立てる。

観察する指標の代表は、以下の通り。

CPU使用率
メモリ使用率
ロードアベレージ
ネットワークトラフィック

サーバ管理の効率化

サーバを複数台運用する場合、一つ一つ人手で設定すると、設定漏れが発生する。
複数のサーバの設定管理を、まとめて、効率的に実施したい。

サーバ管理ツールを導入することで、これらを達成できる。

特に、以下における設定の反映を効率化できる。

新規サーバの投入時
既存サーバの設定変更時

t0mmy

学習履歴詳細