優れたシステムトラブルシューティングツールがすべてです。ただし、優れたツールを見つけるのは困難です。幸いなことに、Linuxには、アプリケーションのボトルネックから設定ミス、さらにはバグまで、システムの動作の問題をプロファイリング、分析、解決できる優れたプログラムとユーティリティが豊富に用意されています。すべては、必要な指標を取得して必要なデータを提供できるツールから始まります。
ヘルスチェックは、プロセスを監視およびプロファイリングできる優れたプログラムであるため、過剰なリソース使用量または関連する問題を特定して解決できます。他の群衆と比較して際立っている点-システムデータの多くの有用な側面を同時に提供することを目的としているため、システムのコンポーネント検索、パフォーマンスの問題のトラブルシューティング、および環境での構成の問題の修正をより簡単に行うことができます。 5つのツールを同時に実行したり、必要なすべての情報を取得するために5回実行したりするのではなく、ヘルスチェックを使用するだけで、ボブは遠い親戚です。良い。大丈夫、準備はいいですか？続行します。
ヘルスチェックインアクション
ユーティリティを怒りで実行する前に、いくつかの小さなメモがあります。 1つは、このツールを実行するにはsudo権限が必要ですが、実際のアプリケーションはシステム上の他のユーザーのコンテキストで実行できます（-uフラグを使用）。 2つ目は、結果を利用するためにLinuxがどのように機能するかをある程度理解する必要があります。このトピックに関する記事がたくさんあり、以下にリンクされています。
本質的に、先ほど概説したように、ヘルスチェックはさまざまなプログラムの機能を1つの傘の下にブレンドします。これは、netstat、lsof、vmstat、iostatを実行し、/procおよび/sysの下でさまざまな構造体を調べた場合に得られる要素をうまくブレンドします。これは、vmstat、iostat、ifstatの機能を組み合わせたdstatに似ています。単純な実行（-bフラグ）から始めることができます：
sudo ./health-check -u "user" -b "binary"
この「ブリーフ」モードでも、次のような大量の出力があります。
CPU使用率（1 CPUに関して）：
ユーザー：34.24％、システム：13.30％、合計：47.54％（高負荷）
まず、コアごとに正規化された基本的なCPUの数値を取得します（100％=1フルコア）。ヘルスチェックには、これが低、中、高のいずれの負荷であるかを示す内部しきい値があります。これは、あなたが何を期待すべきかをあなたに理解させるためだけのものです。詳細は、プロファイリングするアプリケーションとワークロードのタイプによって異なります。 GUIツールとコマンドラインツール、データベースから読み取るソフトウェアと読み取らないソフトウェア、多数の共有ライブラリを備えたソフトウェア、ハードウェアの使用などには違いがあります。
ページフォールト：
PIDプロセスマイナー/秒メジャー/秒合計/秒
1043 google-chrome 16156.46 0.25 16156.71
過去にページフォールトについて詳しく話しました（以下の詳細セクションのリンク）。アプリケーションが何をしているのかわからない場合は、数字だけではあまりわかりません。ただし、同じタイプの2つの異なるプログラム、同じプログラムの2つの異なるバージョン、または2つの異なるプラットフォームで実行されている同じプログラムなどの比較研究には非常に役立ちます。
コンテキストスイッチ：
13687.53コンテキストスイッチ/秒（非常に高い）
コンテキストスイッチの値は、カーネルがランキューを放棄してタスクを切り替える頻度を示します。ユーザーインタラクティブコンポーネントを備えたインタラクティブプロセス（ブラウザなど）の場合、これらのタスクがプロセッサを占有することを望まないため、実際にはできるだけ多くのコンテキストスイッチが必要です（タスクの実行はできるだけ少なくなります）。実際、長い計算はバッチジョブの兆候です。ここで、コンテキストスイッチがほとんどない場合は、ブラウザなどのインタラクティブ（GUI）アプリケーションに問題があることを示している可能性があります。
ファイルI/O操作：
1秒あたりのI/O操作：312.80オープン、283.49クローズ、768.71読み取り、
410.83書き込み
I / O値は、ベースラインがある場合に役立ちます。また、ハードウェア、バス、ドライバー、ファイルシステムの選択、および同時に実行されているその他のディスク操作など、基盤となるI/Oスタックにも依存します。
ポーリングシステムコール分析：
google-chrome（1043）、ポーリング：
1555タイムアウトゼロの即時タイムアウトコール（非ブロッキングピーク）
1回の繰り返しタイムアウトゼロ以外のポーリングコールタイムアウト
（軽いポーリング）
1125回の即時タイムアウトポーリングされた呼び出しがタイムアウトなしで繰り返されました
（重いポーリングのピーク）
このセクションは、プロファイルされたバイナリのユーザーとの対話性の可能性を示すもう1つの指標です。ポーリングシステムコールは、ファイル記述がI/O操作を実行できるようになるのを待つシステムコールです。通常、これはネットワーク接続を示します。フルランを実行するときに、これをさらに詳しく調べます。
メモリ：
メモリの変更（K /秒）：
PIDプロセスタイプサイズRSSPSS
1043google-chromeスタック32.5127.5927.59（
適度に速く成長）
1043google-chromeヒープ67550.949092.519112.70（非常に
速く成長）
1043google-chromeマップ102764.3327296.2418781.80（非常に
速く成長）
ほとんどの人とほとんどのアプリケーションタイプにとって、メモリ操作はそれほど興味深いものではありません。メモリを大量に消費するワークロードは、デスクトップソフトウェアでは通常ではありません。これらは、データベースや複雑な計算にとって非常に重要になる可能性があります。これは、サーバークラスのシステムで通常行うことです。ただし、この一連の数値を使用して、プラットフォーム、カーネル、およびソフトウェアバージョン間の違いを調べることができます。
オープンネットワーク接続：
PIDプロセスプロト送信受信アドレス
1043 google-chrome UNIX 531.52 K 35.16 K / run / user / 1000 / bus
1043 google-chrome UNIX 0.00 B 88.56 K / run / systemd / journal / ...
1043 google-chrome 64.51 K 0.00 Bソケット：[2737924]
1043 google-chrome 30.55 K 0.00 Bソケット：[2746558]
1043 google-chrome 3.98 K 0.00 Bソケット：[2742865]
...
ネットワーク接続の数値セットにより、netstatおよびlsofと同様の結果が得られますが、送信/受信値も取得されるため、非常に便利です。プログラムがネットワークに関して何をするのかがわかっている場合は、その実行のプロファイルを作成し、ネットワークスタックで考えられる構成の誤りを探すことができます。
より長い（詳細な）実行
より多くの統計を選択することもできます（たとえば、-c -fフラグを使用し、-bフラグを使用しない）。前に説明した各セクションの拡張結果が得られます。これにより、ソフトウェアがどのように動作しているかについての追加の洞察を得ることができます。子プロセスとフォークをトレースしている場合は、実行のシーケンスを確認できます。 CPU統計は、使用状況に基づいて一覧表示され、違反者が最も多いものが一番上に表示されます。
CPU使用率（1 CPUに関して）：
PIDプロセスUSR％SYS％TOTAL％期間
1715 vlc 47.04 8.17 55.21 14.71（高負荷）
1720 vlc 46.91 7.96 54.87 14.43（高負荷） ）
1723 vlc 46.77 7.96 54.74 14.35（高負荷）
...
1721 vlc 1.69 1.08 2.77 1.21（軽負荷）
1722 vlc 0.20 0.07 0.27 0.16（非常に軽負荷） ）
1726 vlc 0.07 0.00 0.07 0.02（非常に軽い負荷）
1742 vlc 0.00 0.00 0.00 0.07（アイドル）
1732 vlc 0.00 0.00 0.00 0.02（アイドル）
1728 vlc 0.00 0.00 0.00 0.06（アイドル）
1719 vlc 0.00 0.00 0.00 0.06（アイドル）
合計971.80161.72 1133.52（CPUが完全にロードされている）
上記の例では、VLC（約14秒のHDクリップ再生）を実行して、CPU時間の1,133％を使用しました。これは、11.33CPUコアに相当します。それはかなり聞こえますが、システムには8つのコア（スレッド）があるため、これは事実上、ビデオに実際に使用されたのは1.5コアのみであることを意味します。どのコアが使用されたかを実際に知ることも興味深いでしょう。
コンテキストスイッチ：
PIDプロセス自発的非自発的合計
Ctxt Sw / Sec Ctxt Sw / Sec Ctxt Sw / Sec
1744 vlc 2500.09 1.15 2501.24（高）
1723 vlc 1493.47 1.82 1495.29（高）
1740 vlc 1224.03 3.31 1227.33（高）
1717 vlc 947.43 0.40 947.84（かなり高い）
1731 vlc 736.37 0.81 737.18（かなり高い）
ページフォールトについては、新しいことは何もありません。コンテキストスイッチを使用すると、自発的および非自発的なCSのリストも取得します。後者の束は、割り当てられたスライスを超えるタスクを示している可能性があり、その結果、次回の実行時に動的優先度が低くなります（これはインタラクティブプロセスには適していません）。
ファイルI/O操作：
PIDプロセスカウント操作ファイル名
1715 vlc 176 R /home/roger/developers.webm
1715 vlc 48 C /etc/ld.so.cache
1715 vlc 48 O /etc/ld.so.cache
1715 vlc 34 R /usr/share/X11/locale/locale.alias
ファイルI/Oには、プロセスごとの操作の数、操作のタイプ、およびファイル名も表示されるようになりました。これはディスク上の実際のファイルである必要はなく、バスの場合もあります。使用可能な操作は、このセクションの下部に印刷されています。読み取りおよび書き込み操作がどの程度正確に行われるかは、多くの要因によって異なります。
...
1715 vlc 1 C /lib/x86_64-linux-gnu/libnss_systemd.so.2
1715vlc1または/usr/ bin /vlc
合計4352
Op ：O =開く、R =読み取り、W =書き込み、C=閉じる
これらのI/O操作の頻度もわかります。
1秒あたりのファイルI/O操作：
PIDプロセスオープンクローズ読み取り書き込み
1715 vlc 100.57 96.72 89.77 1.75
1719 vlc 3.24 4.99 3.04 0.00
...
次のセクションはすべてシステムコールに関するもので、非常に詳細です。出力はstraceに似ています。プロセスID、プロセス名、システムコール、カウント、レート、合計時間（私たちの場合）、および各システムコールが合計実行時間に占める割合がわかります。アプリケーションが何をするのかを理解していない限り、またはベースラインと比較できない限り、これらの数値を解釈することはできません。
トレースされたシステムコール：
PIDプロセスシステムコールカウントレート/秒合計uSecs％コール時間
1715 vlc stat 429 28.9555 3004 0.0011
1715 vlc mmap 240 16.1989 4912 0.0017
1715 vlc mprotect 203 13.7015 4739 0.0017
...
この情報は、システムコールのポーリングを確認するときに役立ちます。簡潔にするために、以下の出力を少し編集しました。最後の4つのフィールドはすべてタイムアウトを示します。たとえば、ゼロタイムアウト、最小タイムアウトなどです。基本的に、これらのフィールドは、これらのシステムコールが完了するまでにかかった時間を示します。 Infinite countフィールドは、（アプリケーションの実行中に）無限に待機したシステムコールを指します。情報は、プロセスごとのヒストグラムとしても表示されます。ゼロから無限まで、対数的にバケット化され、最大10us、10-99 us、100-99usなどです。
トップポーリングシステムコール：
PID Process Syscall Rate / Sec Inf Zero Min Max Avg
1715 vlc poll 3.2398 45 1 0.0 s 25.0 s 1.0 s
1715 vlc rt_sigtimed 0.1350 2 0 0.0 s 0.0 s 0.0 s
1717 vlc poll 124.7312 5 1 0.0 s 30.0 s 958.4 ms
...
より詳細な出力ログには、ファイルシステム同期データも含まれます。
ファイルシステム同期：
PID fdatasync fsync sync syncfs合計（レート）
1723 0 2 0 0 2 0.13
ファイル同期：
PID syscall＃syncのファイル名
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.lock
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.XM1715
最後に、詳細な出力にはメモリとネットワーク接続の情報も含まれますが、主な違いはプロセスごとに表示される結果です。前に説明したように、前者は通常、ほとんどのデスクトップワークロードには役立ちませんが（プログラムの開発者でない限り）、後者はネットワークスタックの問題を見つけるのに役立ちます。
ヘルスチェックは非常に多くの結果を作成しますが、アプリケーションがどのように動作するかについて多くの洞察を提供します。その使用法を他のソフトウェアと組み合わせて、ソフトウェアの完全な分析を取得し、パフォーマンスの問題をトラブルシューティングすることができます。ヘルスチェックでは、実行中のタスク（-pフラグ）をプロファイリングすることもできます。これにより、問題解決ツールボックスへの追加として非常に便利になります。
手動セットアップ
リポジトリで使用可能なバージョンに満足できない場合は、手動でコンパイルできます。これを行うもう1つの理由は、ツールが/ proc / timer_statsにアクセスしようとするtimer_statsエラーなど、古いバージョンで発生する可能性のある問題を回避するためですが、この構造体は最近のカーネルでは公開されなくなりました：
>/ proc/timer_statsを開くことができません。
実際、確認すると、次のようになります。
cat / proc / timer_stats
cat：/ proc / timer_stats：そのようなファイルやディレクトリはありません
コンパイルするには、次のコマンドを実行します：
git clone https://kernel.ubuntu.com/git/cking/health-check.git/
cd health-check
make
次のエラーが表示される場合があります：
json.h：25：10：致命的なエラー：json-c / json.h：そのようなファイルまたはディレクトリはありません
#include
これは、ツールが正常にコンパイルするために必要なJSONの開発パッケージが欠落していることを意味します。パッケージの実際の名前はディストリビューションごとに異なりますが、Kubuntuでの私のテストでは、以下によってコンパイルエラーが解決されました。
sudo apt-get install libjson-c-dev
続きを読む
システムのトラブルシューティングに関する追加のツールに興味がある場合は、次のようにします。
Linuxスーパーデュパー管理ツール：strace
Linuxスーパーデュパー管理ツール：lsof
Linuxスーパーデュパー管理ツール：gdb
遅いシステム？救助へのパフォーマンス！
LinuxシステムデバッグスーパーチュートリアルLinuxのクールなハック（パート1から4）は、最後のハックだけをリンクします。
最後になりましたが、私の問題解決の本です！
結論
ヘルスチェックは非常に便利で実用的なツールです。 strace、netstat、perfに代わるものではありませんが、プロファイリングしているものすべての非常に正確な多次元スナップショットを取得するのに役立ちます。これは、正しい方向に向けることができる非常に優れた最初のステップです。次に、ソフトウェア実行の関連する側面を具体的に調べるユーティリティを選択できます（ネットワークの場合はWireshark、メモリの場合はValgrindなど）。ある意味で、これによりヘルスチェックがジャック・オ・オール・トレードになります。
Linuxシステムがどのように機能するか、そして実行しているアプリケーションについてある程度理解する必要があります。ただし、その知識がなくても、ヘルスチェックを使用して、パフォーマンスのボトルネックの比較研究やトラブルシューティングを行うことができます。何かが正常に実行されていないことがわかっている場合は、良いシステムで1回、悪い（影響を受けた）システムで1回トレースしてから、2つを比較できます。ヘルスチェックが提供する多くの種類のデータは、問題の解決に大いに役立ちます。これで、このチュートリアルは終了です。運が良かったので、何か新しいことを学びました。それも楽しい乗り物でした。気をつけて。