サーバが高負荷になったときに確認したいポイント

こんにちは。
今年入社しました、新人社員のtnです。

入社して半年ほどが経ち、日々の運用業務の中でさまざまなアラートを見る機会が増えてきました。

以前の記事では、新人目線で「サーバログを見るときにまず意識したいポイント」について紹介しました。

最近ではログを確認するだけでなく、

「なぜ負荷が高くなっているのか」
「どのプロセスが負荷をかけているのか」
「アクセスが原因なのか、それとも別の処理が原因なのか」

といったところまで確認する機会も増えてきました。

今回は、サーバの負荷が高くなったときに、私が確認するようになった基本的なポイントを整理してみます。

1.まずはサーバ全体の状態を確認する

高負荷のアラートが発生した場合、まずは現在のサーバ全体の状態を確認します。

よく使うコマンドのひとつが w です。

w

実行すると、以下のような情報を確認できます。

10:30:01 up 30 days, 2:15, 1 user, load average: 1.25, 1.10, 0.95

ここで確認しているのが load average です。

load average には、左から順におおよそ

・直近1分
・直近5分
・直近15分

のシステム負荷が表示されます。

ただし、load average の数値が高いからといって、それだけでサーバに問題があるとは限りません。

CPUのコア数や、どのような処理が動いているかによっても見方が変わります。

そのため、load average だけで判断せず、ほかの情報とあわせて確認することが大切だと感じました。

2.topでCPUやメモリの状態を確認する

次に top コマンドを使って、CPUやメモリ、実行中のプロセスを確認します。

top

たとえばCPUの表示では、以下のような項目があります。

%Cpu(s): 20.0 us, 5.0 sy, 0.0 ni, 75.0 id, 0.0 wa

最初のうちは数字が多く、どこを見ればよいのか分かりませんでした。

現在は、まず以下のような項目を見るようにしています。

・us
ユーザープロセスが使用しているCPU

・sy
OSなどのシステム処理が使用しているCPU

・id
何も処理していないCPUの割合

・wa
ディスクなどのI/O処理を待っている割合

たとえば、あるプロセスのCPU使用率が100%と表示されていても、CPU全体の id が70%残っている場合があります。

この場合、ひとつのプロセスがCPUを多く使用していても、サーバ全体としてはまだCPUに余裕がある可能性があります。

最初は「100%」という数字を見るだけでサーバ全体が高負荷なのかと思ってしまうことがありましたが、全体のCPU使用率と個別プロセスのCPU使用率は分けて考える必要があると分かりました。

3.どのプロセスが負荷をかけているか確認する

CPU使用率が高い場合は、どのプロセスがCPUを使用しているのか確認します。

top でも確認できますが、以下のように ps を使用することもあります。

ps -eo pid,user,pcpu,pmem,etime,args –sort=-pcpu | head -20

このコマンドでは、CPU使用率が高い順にプロセスを確認できます。

主に確認している項目は、

・PID
・実行ユーザー
・CPU使用率
・メモリ使用率
・プロセスが動いている時間
・実行されているコマンド

などです。

たとえば、

PID USER %CPU %MEM ELAPSED COMMAND
12345 example 95.0 1.2 02:30 php-fpm: pool example.jp

のように表示されていた場合、example.jp というWebサイトのPHP処理がCPUを多く使用していることが分かります。

ここで注意したいのが、瞬間的にCPU使用率が高くなっているだけなのか、長時間高い状態が続いているのかという点です。

プロセスが起動した直後に一瞬だけCPU使用率が高くなることもあります。

そのため、1回の確認だけで判断せず、少し時間をおいて何度か確認することも大切です。

4.メモリ不足ではないか確認する

CPUだけではなく、メモリの状態も確認します。

free -h

実行すると、メモリやSwapの使用状況を確認できます。

           total        used        free      shared  buff/cache   available

Mem: 15Gi 3Gi 1Gi 500Mi 11Gi 12Gi
Swap: 4Gi 800Mi 3.2Gi

ここで free の値だけを見ると、「空きメモリが少ない」と感じることがあります。

Linuxでは、空いているメモリをキャッシュとして利用することがあるため、私は available もあわせて確認するようにしています。

また、Swapが使用されているからといって、現在メモリ不足が発生しているとは限りません。

過去にSwapへ退避されたデータがそのまま残っている場合もあります。

そのため、

・available が十分残っているか
・Swapの使用量が増え続けていないか
・実際にメモリ不足のログが出ていないか

などをあわせて確認します。

メモリ不足によってプロセスが強制終了された場合は、以下のようなキーワードでログを確認することもあります。

grep -iE ‘out of memory|oom|killed process’ /var/log/messages

環境によっては journalctl や dmesg を確認する場合もあります。

5.Webサーバの場合はアクセス状況も確認する

CPUを多く使用しているプロセスが php-fpm やApache、Nginxなどの場合は、Webアクセスが原因になっていないか確認します。

アクセスログから、アクセス数の多いIPアドレスを確認することがあります。

たとえばApacheのアクセスログであれば、以下のようなコマンドです。

awk ‘{print $1}’ /var/log/httpd/access_log
| sort
| uniq -c
| sort -nr
| head

結果は以下のようになります。

150 192.0.2.10
80 192.0.2.20
25 192.0.2.30

特定のIPアドレスからアクセスが集中していることが分かった場合は、そのIPがどのURLへアクセスしているのか確認します。

grep ‘192.0.2.10’ /var/log/httpd/access_log | tail -n 100

WordPressを利用しているサイトでは、

/wp-login.php
/wp-admin/
/xmlrpc.php
/wp-admin/install.php

などへのアクセスを確認することがあります。

ただし、アクセス数が多いという理由だけで、不正アクセスと判断することはできません。

検索エンジンのクローラーや正常なサービスからのアクセスなど、正当なアクセスである可能性もあります。

そのため、

・アクセス数
・アクセスしているURL
・アクセス間隔
・User-Agent
・レスポンスコード

などを確認してから判断することが大切だと思います。

6.CPUだけでなくI/Oも確認する

CPU使用率がそれほど高くないのにload averageが高い場合は、ディスクI/Oなどが関係していることもあります。

top のCPU表示にある wa が高くなっている場合は、I/O待ちが発生している可能性があります。

環境によっては、以下のように iostat を使用して確認することがあります。

iostat -xz 1 5

iostat では、ディスクの使用状況やI/O待ち時間などを確認できます。

私はまだ各項目をすぐに判断できるほど慣れてはいませんが、

「CPU使用率が高いのか」
「ディスク処理を待っているのか」

を分けて考えることが重要だと感じています。

7.発生時刻の前後も確認する

高負荷調査でも、以前の記事で紹介した「発生時刻の前後を見る」という考え方は重要だと思います。

たとえば、毎日決まった時間に負荷が高くなる場合、

・バックアップ処理
・ログローテーション
・cronで実行されるバッチ処理
・ウイルススキャン
・アクセス集中

などが関係していることがあります。

現在の状態だけを見るとすでに負荷が下がっていて、原因が分からない場合もあります。

そのため、アラートが発生した時刻を確認し、その時間帯のログや定期処理と照らし合わせるようにしています。

cronについて確認する場合は、環境によって異なりますが、以下のように設定を確認することがあります。

crontab -l

また、

ls -l /etc/cron.d/

などでシステム側に設定されている定期処理を確認することもあります。

8.ひとつの数値だけで原因を決めつけない

高負荷の調査をするようになって、一番意識するようになったのが「ひとつの数値だけで判断しない」ということです。

たとえば、

CPU 100%

と表示されていても、サーバ全体ではCPUに余裕が残っていることがあります。

load averageが高くても、CPUが原因ではなくI/O待ちが発生している場合もあります。

また、アクセス数の多いIPが見つかっても、そのIPが必ず攻撃元とは限りません。

そのため、

サーバ全体の状態
↓
負荷の高いプロセス
↓
対象となっているサービス
↓
アクセスログやエラーログ
↓
発生時刻の前後

というように、少しずつ範囲を絞りながら確認することが大切だと感じています。

まとめ

今回は、新人目線でサーバが高負荷になったときに確認したいポイントを整理しました。

高負荷の調査では、

・まずサーバ全体の負荷を確認する
・CPU、メモリ、I/Oのどこに負荷があるか確認する
・負荷の高いプロセスを確認する
・Webサーバであればアクセス状況も確認する
・発生時刻の前後や定期処理も確認する
・ひとつの数値だけで原因を決めつけない

といった点が大切だと思います。

入社したばかりの頃は、アラートが発生するとまず「何か対応しなければ」と考えてしまうこともありました。

半年ほど運用業務を経験して、まず現在の状態を確認し、情報をひとつずつ集めて原因を切り分けていくことが重要だと少しずつ分かってきました。

まだ、確認した情報からすぐに原因を判断できないことも多いですが、CPU、メモリ、プロセス、ログなどを関連付けて見ることで、以前よりも状況を整理しやすくなったと感じています。

今後も、日々の運用業務の中で経験したことを少しずつ整理していきたいです。