ベストプラクティス：Linuxの「トップ」コマンドを使用したトラブルシューティング

現在、サーバーの外部パラメーターだけでなく、システムの読み込み、ハードドライブの状態、RAMなどの内部パラメーターも監視できるようにするために、 監視サービスの新しい機能に取り組んでいます。 開発の過程で、top systemコマンドを使用して取得できるシステムパラメーターについて説明する有用な記事に出会いました;この記事の翻訳をユーザーの注意を喚起します。



負荷平均は、サーバーのパフォーマンスメトリックとして扱いにくい場合があります。 この記事では、「top」コマンドの出力と他のLinuxコマンドの出力にある値が何を意味するのかを理解しようと試みます。 また、この記事では、共有ホスティングに固有のパラメーターについても説明しています。これらのパラメーターは通常、topコマンドの標準出力には表示されません。

「top」コマンドの出力

Linuxシステムのコマンドラインにコマンドトップを入力すると、次の見出しのプレートが表示されます。







各行の意味を見てみましょう。



top – 17:15:19 up 32 days, 18:24, 6 users





コマンドと現在のシステム時刻がここに表示されます。 「アップタイム」は、私たちの場合、32日、18時間24分です。 最後に、システムに登録されているユーザーの数が示されます。 この例では、6人のユーザーがシステムに登録されています。 SSHを介してローカルに接続したり、非アクティブにしたりできます。



load average: 0,00, 0,01, 0,05





この部分は平均負荷を示しています。 特に仮想マシン/クラウドでは、混乱を招く可能性があります。

最初の桁は、「最後の1分間」の平均負荷、または「現在の」平均負荷を示します。 2桁目は「5分間の平均負荷」、最後の桁は「15分間の平均負荷」を示しています。

平均負荷は、プロセッサで何らかのアクションを実行するために並んで待機しているプロセスの平均数の尺度です。 スーパーマーケットのように、レジ係があなたにすべての注意を払うのを待って並んでいる必要があります。 平均負荷が増加している理由は、この行の下にある残りの統計とカウンターのためです。したがって、平均負荷値に厳密に焦点を当てると、全体像が完全に表示されない場合があります。

distccノードからの例を以下に示します。

このサーバーは、スクリプトの中間処理環境であり、クラウドコマンドラインツールをホストすることに加えて、8プロセッサ、32 GBのRAM、および1トンの擬似ディスク領域があるため、ネットワーク上のさまざまなマシンに分散Cコンパイラサービスを提供します。 通常の負荷では、その平均値は比較的低いままです。 Javaスクリプトを実行すると、負荷が2回以上増加する可能性があります。 ただし、コンパイラサービスが全負荷で実行されている場合（プロセッサの負荷が95％以上の場合、10個の実行プロセス）、平均負荷は0.75です。これはどうですか。 それを理解してみましょう

タスク文字列

Tasks: 119 total, 1 running, 118 sleeping, 0 stopped, 0 zombie





タスク：たとえば「ps aux」と入力すると、プロセスの数が表示されます。

• total制御不能なApacheサーバーまたはpostgresqlインスタンスを識別するためにタスクの総数を知ることは有用ですが、通常はかなり安定しています。

• 実行中実行中のプロセスの数は、プロセッサが現在どのように使用されているかを示します。 原則として、一度にマルチスレッドを持たないアプリケーションは1つのプロセッサを使用できるため、通常の状況では、1つのプロセスがクアッドコアサーバーのプロセッサの平均負荷が〜1の25％を使用します。

• スリープ待機中のプロセスの数は、実行されているがアクティブではないプロセスを示します。 これらは通常、バックグラウンドタスク、システムソフトウェア、プリンタードライバーなどです。

• 停止停止したプロセスの数は、トラブルシューティングのためにプロセスにSIGSTOPまたはkill -STOPシグナルを送信しない限り、通常0である必要があります。 この数が0と異なる場合、実稼働サーバーの場合、これが懸念の原因である可能性があります。

• ゾンビハンギングプロセス。 これは、マルチスレッドアプリケーションが子プロセスを開始した後、強制終了または予期せず終了し、ゾンビプロセスと呼ばれるぶら下がりプロセスが残ることを意味します。 Apacheは、通常とは異なる何かが発生した場合に、そのようなプロセスを大量に生成できます。 通常、それらの番号も0でなければなりません。

ストリングCPU

この情報を2つの部分に分けます。これらの情報には、使用に重要な統計が含まれています。



Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.9%id,





ここに示されている最初の4つの値は、Linuxを搭載したすべてのサーバーに存在し、ほとんどの人によく知られています。

• ％usは、最大値100％までの個別のプロセッサ（apache、mysqlなどのユーザープロセスによる）の使用を示します。 したがって、プロセスがクアッドコアプロセッサ1で100％CPUを使用する場合、25％の値usが得られます。 8コアプロセッサの12.5％という値は、1つのコアがビジーであることを意味します。

• ％syは、CPUがシステムを使用していることを意味します。 通常、この値は高くありません。その高い値は、カーネル構成の問題、ドライバーの問題、または他の多くのことを示している可能性があります。

• ％niは、niceまたはreniceコマンドの使用によって影響を受けるユーザープロセスによって使用されるCPUの割合を意味します。 基本的に、それらの優先度は、スケジューラーによって割り当てられたデフォルトの優先度からより高いまたはより低い値に変更されています。 niceコマンドがプロセスに割り当てられている場合、正の数値は低い優先順位（1 =通常より1ステップ低い）を意味し、負の数値は高い優先順位を意味します。 0がデフォルト値です。これは、スケジューラーが優先順位を決定することを意味します。 システムで使用されているスケジューラを判別できますが、これは以下の記事ではより複雑なトピックです。 さらに、この記事に記載されているパーセンテージ値は、％us値と重複していません。この値は、優先順位が未定のユーザープロセスのみを示しています。

• ％id -100.0％から以前の3つの値を減算し、「アイドル」コンピューティングパワーを測定した結果。



0.0%wa, 0.0%hi, 0.0%si, 0.0%st





2番目の値のセットは仮想化に関連しており、おそらく平均負荷が高い原因となる問題を正確に追跡できるのは、仮想化に関するものです。



• ％wa -iowait、プロセッサがアイドル状態でI / O操作の完了を待機していた時間の割合（サイクル、秒）。 プロセスまたはプログラムがデータを要求すると、最初にプロセッサのキャッシュ（2つまたは3つのキャッシュがあります）をチェックし、次にメモリをチェックして、最後にディスクに到達します。 ディスクに到達すると、プロセスまたはプログラムは通常、入出力ストリームがRAMに情報を転送するまで待機してから、再度作業できるようになります。 ディスクが遅いほど、各プロセスのIO Wait％値が高くなります。 これは、システムバッファがいっぱいで、カーネルでクリーンアップする必要がある場合にもディスクへの書き込みで発生します。これは通常、高負荷のデータベースサーバーで発生します。 IO待機の値が安定して{100 /（CPUの数*プロセスの数）}％を超える場合、これは対処する必要があるストレージの問題がある可能性があることを意味します。 平均負荷が高い場合は、まずこのパラメーターを確認してください。 高い場合は、ディスクに蓄積されているプロセスのボトルネックであり、他のボトルネックではありません。

• ％hiは、鉄レベルでの中断を意味します。 回路基板上では、電子は予測可能な方法でチップ内を移動します。 たとえば、ネットワークカードがパケットを受信すると、パケットに含まれる情報をコア経由でプロセッサに転送する前に、マザーボードの割り込みチャネルで割り込みを要求します。 プロセッサは、ネットワークカードに情報があることをカーネルに伝え、カーネルは何をすべきかを決定する能力を持っています。 仮想マシンでは、鉄レベルで割り込みの処理に費やす時間の価値が高いことは非常にまれですが、ハイパーバイザーが仮想マシンで使用できるハードウェアを増やすにつれて、この状況は変化する可能性があります。 極めて高いネットワーク帯域幅、USBの使用、GPUでのコンピューティング-これらすべてにより、このパラメーターが数パーセントを超えて増加する可能性があります。

• ％si-ソフトウェアレベルでの中断。 Linuxバージョン2.4カーネルは、マザーボードの割り込みチャネルで割り込みを要求するハードウェア要素またはデバイス（ドライバー）ではなく、ソフトウェア（アプリケーション）による割り込みを要求する機能を実装しています。 要求は、割り込みハンドラーを介してカーネルによって処理されます。 これは、アプリケーションが優先順位ステータスを要求でき、カーネルがコマンドの受信を確認でき、ソフトウェアが割り込みが処理されるまで辛抱強く待つことを意味します。 高トラフィックのギガビットチャネルにtcpdumpユーティリティを適用すると、値は約10％変化する可能性があります-割り当てられたtcpdumpメモリがいっぱいになると、ユーティリティはバスから割り込みにデータをスタックからディスク、画面、またはその他の場所に移動します。

• ％stはリストから最も重要なパラメーターです。私の意見では、これはIOSteal％です。 仮想化環境では、多くの論理サーバーが同じ実際のハイパーバイザーの下で実行できます。 4〜8個の「仮想」CPUを割り当てる各仮想マシン（VM）。 ただし、ハイパーバイザー自体にはない場合があります（VMの数* VMごとの仮想CPUの数）。 これは、仮想マシンを使用してCPUを過負荷にしないため、1つまたは2つのVMが8つのプロセッサを使用することを許可しても、プール全体に悪影響を与えないためです。 ただし、仮想VMプロセッサが使用するCPUの数が物理（またはXeonハイパースレッドプロセッサの場合は論理）の数を超えると、osteal値が増加します。



iosteal％-ハイパーバイザーのワークロードの測定。 iosteal％パラメーターの値が一貫して高い（15％以上）ことを示すプール内の仮想マシンの存在は、プールの別の部分に一部のVMを転送する必要があることを示している可能性があります。



iowait％はディスクパフォ​​ーマンスの測定値です。 NetAppがサポートするストレージシステムでは、使用率の低いドライブまたは他のNetAppドライブにボリュームを移動しないとパフォーマンスの問題を解決できない場合があります。 ローカルディスク（SSDまたはSAS）の場合、これはディスクリソースを集中的に使用しているハイパーバイザー内のVMが多すぎることを意味する場合があり、これらのVMの一部をプールの別の部分に転送する必要がある場合があります。

要約すると：

•実際には、平均負荷は何の意味もありません。

•パラメータ％userland（％us）は 、計算が行われていることを示すため、平均負荷にとって重要です。 たとえば、mysqlは1つのスレッドのみを使用するため、全負荷（1 / VMによって割り当てられた仮想CPUの数）で使用します。 postgresqlはマルチスレッド化されており、割り当てられている場合はより多くのプロセッサを使用できます。

• ％st-iosteal％ -ハイパーバイザーワークロードのインジケーター。 1つのハイパーバイザーの下に4つのpostgresqlと6つのTomcatサーバーのスタックを作成することは、ビジネスの観点からは合理的かもしれませんが、CPU時間を常に競う必要があります。

• ％wa-iowait％ -使用するストレージソリューションに関係なく、プロセスを非常に遅いディスクに送信するのにかかる時間の指標。 ドライブは、SSDであっても比較的低速です。 RAMを追加してカーネルバッファーを増やすと、問題が少し緩和される場合があります。 RAMは、ディスクと比較して非常に高速であるため、ディスクよりも安価です。

追加のチーム

iostat





iowaitまたはiostealパラメーターの値が高い場合は、iostatコマンドを使用して、どのドライブがこの原因であるかを正確に追跡できます。 次のように始まります。







詳細については、iostatのマニュアルを参照してください。 内訳は、1秒ごとに表示され、そのディスクの読み取り元と書き込み元、およびこれらのディスクへのアクセスに関連付けられたすべてのiostealまたはiowait値が表示されました。



htop





LinuxシステムでのCPUとプロセスの使用に関するチーム。 仮想統計は表示しませんが、プロセスのツリーと、システム内の各プロセッサーの内訳、その使用状況を表示します。 さらに、スワップとメモリの統計情報を表示して、不快なメモリリークを追跡し、きれいな色ですべてを着色します。 私の意見では、このパッケージはすべてのVMに必須です。



小さな広告。 冒頭で述べたように、クローズドベータテストに参加したい場合は、現在、内部サーバーパラメーターの監視を積極的にテストしています。ht2support@ host-tracker.comまでご連絡ください。