ウェブサイト検索

システムの使用状況、停止を監視し、Linux サーバーのトラブルシューティングを行う方法 - パート 9


Linux は非常に信頼性が高いですが、賢明なシステム管理者は、システムの動作と使用状況を常に監視する方法を見つける必要があります。可能な限り100% に近い稼働時間とリソースの可用性を確保することは、多くの環境において重要なニーズです。システムの過去と現在のステータスを調査することで、起こり得る問題を予測し、おそらく防ぐことができます。

Linux Foundation 認定プログラムの紹介

この記事では、システムのステータスを確認し、停止を分析し、進行中の問題をトラブルシューティングするために、ほとんどのアップストリーム ディストリビューションで利用できるいくつかのツールのリストを紹介します。具体的には、利用可能な無数のデータのうち、CPU、ストレージ容量、メモリの使用率、基本的なプロセス管理、ログ分析に焦点を当てます。

ストレージスペースの使用率

Linux には、ストレージ領域の使用状況を検査するために使用される 2 つのよく知られたコマンド、dfdu があります。

最初の df (ディスク フリーの略) は、通常、ファイル システムごとの全体的なディスク スペース使用量をレポートするために使用されます。

例 1: ディスク容量の使用量をバイト単位で人間が判読できる形式でレポートする

オプションを指定しない場合、df はディスク容量の使用量をバイト単位で報告します。 -h フラグを使用すると、代わりに MB または GB を使用して同じ情報が表示されます。このレポートには、各ファイル システムの合計サイズ (1 ~ K ブロック単位)、空きスペースと使用可能なスペース、および各ストレージ デバイスのマウント ポイントも含まれることに注意してください。

df
df -h

それは確かに素晴らしいことですが、ファイル システムが使用できなくなる可能性がある別の制限があり、それにより i ノードが不足します。ファイル システム内のすべてのファイルは、そのメタデータを含む i ノードにマップされます。

例 2: ファイルシステムごとに i ノードの使用状況を人間が判読できる形式で検査する
df -hTi

使用されている i ノードと使用可能な i ノードの量を確認できます。

上の画像によると、/home には 146 個の i ノード (1%) が使用されています。これは、そのファイル システムでまだ 226K のファイルを作成できることを意味します。

例 3: 空のファイルおよびディレクトリの検索および/または削除

i ノードが不足するずっと前にストレージ領域が不足する可能性があることに注意してください。また、その逆も同様です。そのため、ストレージ領域の使用率だけでなく、ファイル システムが使用する i ノードの数も監視する必要があります。

理由なく i ノードを使用している空のファイルまたはディレクトリ (0B を占有) を見つけるには、次のコマンドを使用します。

find  /home -type f -empty
find  /home -type d -empty

また、空のファイルやディレクトリも削除したい場合は、各コマンドの最後に -delete フラグを追加します。

find  /home -type f -empty --delete
find  /home -type f -empty

前の手順では 4 つのファイルが削除されました。 /home で使用済み/利用可能なノードの数をもう一度確認してみましょう。

df -hTi | grep home

ご覧のとおり、現在 142 の i ノードが使用されています (以前より 4 つ減少)。

例 4: ディレクトリごとのディスク使用量を調べる

特定のファイル システムの使用率が事前定義された割合を超えている場合は、du (ディスク使用量の略) を使用して、最も多くのスペースを占有しているファイルを調べることができます。

この例は /var について示されており、上の最初の画像でわかるように、67% で使用されています。

du -sch /var/*

: 上記のサブディレクトリのいずれかに切り替えると、その中に何があるか、各アイテムがどれだけ占有しているかを正確に確認できます。その後、その情報を使用して、必要がない場合は一部のファイルを削除したり、必要に応じて論理ボリュームのサイズを拡張したりできます。

こちらもお読みください

  1. ディスク容量を確認するための 12 の便利な「df 」コマンド
  2. ファイルとディレクトリのディスク使用量を調べるための 10 の便利な「du」コマンド

メモリとCPUの使用率

CPU/メモリ使用率とプロセス管理の全体的なチェックを実行するために使用される Linux の古典的なツールは、top コマンドです。さらに、上部には実行中のシステムのリアルタイム ビューが表示されます。 htop など、同じ目的に使用できるツールは他にもありますが、Linux ディストリビューションにはすぐにインストールできるため、私は top に落ち着きました。

例 5: システムのライブ ステータスをトップで表示する

top を開始するには、コマンドラインに次のコマンドを入力し、Enter キーを押します。

top

典型的なトップ出力を調べてみましょう。

行 1 ~ 5 には、次の情報が表示されます。

1. 現在時刻 (午後 8 時 41 分 32 秒) と稼働時間 (7 時間 41 分)。システムにログオンしているユーザーは 1 人のみで、それぞれ過去 1 分間、5 分間、15 分間の負荷平均です。 0.00、0.01、および 0.05 は、これらの時間間隔において、システムが 0% の時間アイドル状態であり (0.00: CPU を待機しているプロセスがなかった)、その後 1% 過負荷になったことを示します (0.01: 平均 0.01 プロセス) CPU を待機していました)、5% (0.05)。 0 より小さい数値 (たとえば、0.65) の場合、0.65 が表示される場所に応じて、システムは最後の 1、5、または 15 分間に 35% アイドル状態でした。

2. 現在、121 個のプロセスが実行されています (完全なリストは 6 で確認できます)。実行されているのは 1 つだけ (この場合は、%CPU 列でわかるように最上位) で、残りの 120 はバックグラウンドで待機していますが、「スリープ」しており、呼び出すまでその状態のままになります。どうやって?これを確認するには、mysql プロンプトを開いていくつかのクエリを実行します。実行中のプロセスの数がどのように増加しているかがわかります。

あるいは、Web ブラウザを開いて、Apache によって提供されている任意のページに移動すると、同じ結果が得られます。もちろん、これらの例では、両方のサービスがサーバーにインストールされていることを前提としています。

3. us (優先順位が変更されていないユーザー プロセスの実行時間)、sy (カーネル プロセスの実行時間)、ni (優先順位が変更されたユーザー プロセスの実行時間)、wa (I/O 完了の待機時間)、 hi (ハードウェア割り込みの処理に費やした時間)、si (ソフトウェア割り込みの処理に費やした時間)、st (ハイパーバイザーによって現在の VM から盗まれた時間 – 仮想化環境のみ)。

4. 物理メモリの使用量。

5. スワップスペースの使用量。

例 6: 物理メモリ使用量の検査

RAM メモリとスワップの使用状況を検査するには、free コマンドを使用することもできます。

free

もちろん、-m (MB) または -g (GB) スイッチを使用して、同じ情報を人間が読める形式で表示することもできます。

free -m

いずれにせよ、カーネルは可能な限り多くのメモリを予約し、プロセスが要求したときにそれを利用できるようにするという事実を認識する必要があります。特に、「-/+ バッファ/キャッシュ」行は、この I/O キャッシュを考慮した後の実際の値を示しています。

言い換えれば、プロセスによって使用されているメモリの量と、他のプロセスが使用可能なメモリの量 (この場合、それぞれ 232 MB が使用されており、 270 MB が使用可能です)。プロセスがこのメモリを必要とする場合、カーネルは自動的に I/O キャッシュのサイズを減らします。

こちらもお読みください: Linux のメモリ使用量を確認するための 10 の便利な「無料」コマンド

プロセスを詳しく見る

Linux システムでは常に多くのプロセスが実行されています。プロセスを詳細に監視するために使用するツールは、pspstree の 2 つです。

例 7: ps (完全な標準形式) を使用してシステム内のプロセスリスト全体を表示する

-e-f オプションを 1 つに組み合わせて (-ef) 使用すると、システム上で現在実行中のすべてのプロセスを一覧表示できます。この出力を grep などの他のツール (LFCS シリーズのパート 1 で説明) にパイプして、出力を目的のプロセスに絞り込むことができます。

ps -ef | grep -i squid | grep -v grep

上記のプロセス リストには、次の情報が表示されます。

プロセスの所有者、PID、親 PID (親プロセス)、プロセッサー使用率、コマンド開始時刻、tty (? はデーモンであることを示します)、累積 CPU 時間、およびプロセスに関連付けられたコマンド。

例 8: ps の出力のカスタマイズと並べ替え

ただし、そのすべての情報は必要なく、プロセスの所有者、プロセスを開始したコマンド、PID と PPID、現在使用しているメモリの割合をこの順序で表示し、並べ替えたい場合もあります。メモリ使用量は降順で表示されます (デフォルトでは ps が PID でソートされていることに注意してください)。

ps -eo user,comm,pid,ppid,%mem --sort -%mem

%mem の前のマイナス記号は、降順での並べ替えを示します。

何らかの理由でプロセスがシステム リソースを過剰に消費し始め、システム全体の機能が危険にさらされる可能性がある場合は、kill プログラムを使用して次のいずれかのシグナルをプロセスに渡して、プロセスの実行を停止または一時停止する必要があります。これを行うことを検討するその他の理由は、フォアグラウンドでプロセスを開始したが、それを一時停止してバックグラウンドで再開したい場合です。

Signal name Signal number Description
 SIGTERM 15  Kill the process gracefully.
 SIGINT 2  This is the signal that is sent when we press Ctrl + C. It aims to interrupt the process, but the process may ignore it.
 SIGKILL 9  This signal also interrupts the process but it does so unconditionally (use with care!) since a process cannot ignore it.
 SIGHUP 1  Short for “Hang UP”, this signals instructs daemons to reread its configuration file without actually stopping the process.
 SIGTSTP 20  Pause execution and wait ready to continue. This is the signal that is sent when we type the Ctrl + Z key combination.
 SIGSTOP 19  The process is paused and doesn’t get any more attention from the CPU cycles until it is restarted.
 SIGCONT 18  This signal tells the process to resume execution after having received either SIGTSTP or SIGSTOP. This is the signal that is sent by the shell when we use the fg or bg commands.
例 9: 実行中のプロセスの実行を一時停止し、バックグラウンドで再開する

特定のプロセスの通常の実行により、実行中に出力が画面に送信されないことが暗示される場合は、プロセスをバックグラウンドで開始する (コマンドの最後にアンパサンドを追加する) こともできます。

process_name &

または
フォアグラウンドで実行を開始したら、一時停止してバックグラウンドに送信します。

Ctrl + Z
kill -18 PID

例 10: 「暴走した」プロセスを強制的に強制終了する

各ディストリビューションには、SysV ベースのシステムの service や systemd ベースのシステムの systemctl などの共通サービスを正常に停止/開始/再起動/再ロードするためのツールが用意されていることに注意してください。

プロセスがこれらのユーティリティに応答しない場合は、プロセスに SIGKILL シグナルを送信することでプロセスを強制的に強制終了できます。

ps -ef | grep apache
kill -9 3821

それで...何が起こったのか/何が起こっているのですか?

システムに何らかの種類の停止が発生した場合 (停電、ハードウェア障害、プロセスの計画的または計画外の中断、あるいは何らかの異常など)、/var/log 何が起こったのか、またはあなたが直面している問題の原因を判断してくれる親友です。

cd /var/log

/var/log 内の項目の一部は通常のテキスト ファイル、その他はディレクトリ、さらにその他はローテーションされた (履歴) ログの圧縮ファイルです。名前に error という単語が含まれているものをチェックする必要がありますが、残りの部分を検査することも同様に便利です。

例 11: プロセス内のエラーのログを調べる

このシナリオを想像してみてください。 LAN クライアントはネットワーク プリンタに印刷できません。この状況をトラブルシューティングする最初のステップは、/var/log/cups ディレクトリに移動し、そこにあるものを確認することです。

tail コマンドを使用して error_log ファイルの最後の 10 行を表示するか、tail -f error_log を使用してログをリアルタイムに表示できます。

cd /var/log/cups
ls
tail error_log

上のスクリーンショットは、問題の原因を理解するために役立つ情報を提供します。手順に従っても、プロセスの誤動作を修正しても、全体的な問題は解決しない可能性があることに注意してください。ただし、最初から問題が発生するたびに (ローカルの問題でもネットワークの問題でも) ログを確認することに慣れている場合は、間違いなく正しい軌道に乗るでしょう。

例 12: ハードウェア障害のログを調べる

ハードウェア障害のトラブルシューティングは難しい場合がありますが、dmesg とメッセージ ログを確認し、障害が発生していると思われるハードウェア部品に関連する単語を grep する必要があります。

以下の画像は、次のコマンドを使用して単語 error を検索した後の /var/log/messages から取得したものです。

less /var/log/messages | grep -i error

/dev/sdb/dev/sdc の 2 つのストレージ デバイスに問題があり、結果として RAID アレイに問題が発生していることがわかります。

結論

この記事では、システムの全体的なステータスを常に認識するのに役立ついくつかのツールを検討しました。さらに、オペレーティング システムとインストールされているパッケージが最新の安定したバージョンに更新されていることを確認する必要があります。そして、ログの確認を決して忘れないでください。そうすれば、問題に対する決定的な解決策を見つけるために正しい方向に向かうでしょう。

ご意見、ご提案、ご質問がございましたら、以下のフォームを使用してお気軽にお寄せください。