同じ負荷平均でもシステムが異なれば動作も異なることに注意してください。 たとえば、ハードウェア アクセラレーションをサポートするグラフィックス カードを搭載したシステムでは、3D 画像のレンダリングに問題はありませんが、同じシステムで安価な VGA カードを搭載した場合、レンダリング中に大幅に速度が低下します。 私の古い P133 は、X サーバーを起動すると非常に不快になりますが、最新のシステムではシステム負荷の違いにほとんど気づきません。
4.3.5. ユーザーとして何かできるのでしょうか？
大きな環境では速度が低下する可能性があります。 (シェル変数の代わりに) 多くの環境変数が設定されている場合、最適化されていない長い検索パス (パス環境変数の設定エラー)、および通常は「オンザフライ」で行われる設定が多い場合、システムは次のことを行う必要があります。データの検索と読み取りにかかる時間が増えます。
X では、ウィンドウ マネージャーとデスクトップ環境が実際に CPU を消費する可能性があります。 ほとんどのデスクトップにはアドオンが無制限に提供されているため、本当に豪華なデスクトップには、たとえ無料でダウンロードできたとしても価格がかかります。 謙虚さ
毎年新しいコンピューターを購入しないのであれば、それは美徳です。
4.3.5.1。 優先順位
ジョブの優先順位または重要性は、ジョブの内容によって定義されます。 nice 番号。 nice 番号が高いプログラムは、他のプログラム、他のユーザー、システムにとってフレンドリーです。 それは重要な仕事ではありません。 Nice の数値が低いほど、ジョブの重要性が高く、共有しないとより多くのリソースが必要になります。
nice 数値を増やしてジョブをより良くすることは、CPU 時間を大量に使用するプロセス (コンパイラー、数学アプリケーションなど) にのみ役立ちます。 常に大量の I/O 時間を使用するプロセスには、システムによって自動的に報酬が与えられ、より高い優先順位 (より低い Nice 数値) が与えられます。たとえば、キーボード入力はシステム上で常に最高の優先順位になります。
プログラムの優先順位の定義は、 nice
ほとんどのシステムは BSD も提供します renice コマンドを使用すると、 優しさ 実行中のコマンドの。 もう一度、マニュアル ページを読んで、システム固有の情報を確認してください。
良い考えではありません nice or renice 対話型プログラムまたはフォアグラウンドで実行されるジョブ。
これらのコマンドの使用は通常、システム管理者のタスクです。 システム管理者が利用できる追加機能の詳細については、マニュアル ページを参照してください。
4.3.5.2. CPUリソース
どの Linux システムでも、システム上の唯一のユーザーであっても、多くのプログラムが同時に CPU を使用しようとします。 すべてのプログラムを実行するには、CPU 上で一定量のサイクルが必要です。 CPU がビジーすぎるため、十分なサイクルが得られない場合があります。 の uptime このコマンドは非常に不正確ですが (平均値しか表示されないため、何が正常なのかを知る必要があります)、役に立たないわけではありません。 システムが応答しない原因が CPU にあると思われる場合、実行できるアクションがいくつかあります。
• 負荷が低いときに重いプログラムを実行します。 これは夜間にシステムで発生する可能性があります。 スケジュールについては次のセクションを参照してください。
• システムが不必要な作業を行わないようにします。使用しないデーモンやプログラムを停止し、
大量の発見ではなく、場所を特定します...
• 優先度の低い大きなジョブを実行する
特定の状況でこれらの解決策がいずれも選択肢にない場合は、CPU をアップグレードすることをお勧めします。 UNIX マシンでは、これはシステム管理者のジョブです。
4.3.5.3. メモリリソース
現在実行中のプロセスが、システムが物理的に利用可能なメモリを超えるメモリを予期しても、Linux システムはクラッシュしません。 ページングが開始されます。または スワッピングこれは、プロセスがディスク上またはスワップ領域のメモリを使用し、物理メモリの内容 (実行中のプログラムの一部またはスワップの場合はプログラム全体) をディスクに移動し、より多くのプロセスを処理するために物理メモリを再利用することを意味します。 ディスクへのアクセスはメモリへのアクセスよりもはるかに遅いため、これによりシステムの速度が大幅に低下します。 の top コマンドを使用して、メモリとスワップの使用状況を表示できます。 glibc を使用するシステムは、 メモサージュ および memusagestat メモリ使用量を視覚化するコマンド。
大量のメモリとスワップ領域が使用されていることがわかった場合は、次のことを試してみてください。
• 大量のメモリを使用するプログラムを強制終了、停止、または修復する
• システムにメモリを追加します (場合によってはスワップ領域も追加します)。
• システム パフォーマンスのチューニング。これはこのドキュメントの範囲外です。 詳細については、付録 A の図書リストを参照してください。
4.3.5.4. I/Oリソース
I/O 制限はシステム管理者にとってストレスの主な原因ですが、Linux システムが提供する I/O パフォーマンスを測定するためのユーティリティはかなり貧弱です。 の ps, vmstat および top ツールは、I/O を待機しているプログラムの数をある程度示します。 netstat ネットワーク インターフェイスの統計が表示されますが、システム負荷に対する I/O 応答を測定できるツールは事実上ありません。 iostat コマンドは、一般的な I/O の使用法の概要を示します。 これらのコマンドの出力を人間が理解できる形式にするために、さまざまなグラフィカル フロントエンドが存在します。
各デバイスには独自の問題がありますが、ネットワーク インターフェイスで使用できる帯域幅とディスクで使用できる帯域幅が、I/O パフォーマンスのボトルネックの XNUMX つの主な原因です。
ネットワーク I/O の問題:
• ネットワークの過負荷:
ネットワーク上で転送されるデータの量がネットワークの容量を超えているため、すべてのユーザーのネットワーク関連タスクの実行が遅くなります。 この問題は、ネットワークをクリーンアップする (主に、不要なプロトコルとサービスを無効にすることが含まれます) か、ネットワークを再構成する (サブネットの使用、ハブをスイッチに置き換える、インターフェイスと機器をアップグレードする) ことによって解決できます。
• ネットワークの完全性の問題:
データが正しく転送されなかった場合に発生します。 この種の問題を解決するには、障害のある要素を切り分けて交換するしかありません。
ディスク I/O の問題:
• プロセスごとの転送速度が低すぎる:
単一プロセスの読み取りまたは書き込み速度が十分ではありません。
• 総転送速度が低すぎる:
システムが実行するすべてのプログラムに提供できる最大合計帯域幅では十分ではありません。
この種の問題は検出がより難しく、ハードウェアの過負荷が問題の原因である場合は、通常、バス、コントローラー、ディスク上のデータ ストリームを再分割するために追加のハードウェアが必要になります。 これを解決する XNUMX つのソリューションは、入出力アクションに最適化された RAID アレイ構成です。 こうすることで、同じハードウェアを維持できるようになります。 通常は、より高速なバス、コントローラ、ディスクへのアップグレードがもう XNUMX つの選択肢です。
過負荷が原因ではない場合は、ハードウェアが徐々に故障しているか、システムに適切に接続されていない可能性があります。 まずは接点、コネクタ、プラグを確認してください。
4.3.5.5 ユーザー
ユーザーは、リソースの使用状況に応じて、いくつかのクラスに分類できます。
• (多数の) 小さなジョブを実行するユーザー: たとえば、初心者の Linux ユーザーです。
• 比較的少数だが大規模なジョブを実行するユーザー: シミュレーション、計算、エミュレータ、またはメモリを大量に消費するその他のプログラムを実行するユーザー。通常、これらのユーザーには大きなデータ ファイルが伴います。
• 実行するジョブはほとんどないが、CPU 時間を多く使用するユーザー (開発者など)。
システム要件はユーザーのクラスごとに異なる可能性があり、すべての人を満足させるのは難しいことがわかります。 マルチユーザー システムを使用している場合、特定の目的に合わせてシステムを最大限に活用するために、他のユーザーやシステムの習慣を調べることは便利です (そして楽しいです)。
4.3.5.6。 グラフィカルツール
グラフィカル環境では、多数の監視ツールが利用可能です。 以下は、プロセス情報の表示と検索、およびシステム リソースの監視機能を備えた Gnome System Monitor のスクリーン ショットです。
図4-3。 Gnome システム モニター
ディスク、メモリ、負荷モニターなど、タスク バーにインストールできる便利なアイコンもいくつかあります。 xload これは、システム負荷を監視するためのもう XNUMX つの小さな X アプリケーションです。 お気に入りを見つけてください！
4.3.5.7. プロセスを中断する
非特権ユーザーは、自分のプロセスにのみ影響を与えることができます。 プロセスを表示し、特定のユーザーに属するプロセスをフィルターで除外する方法と、発生する可能性のある制限についてはすでに説明しました。 プロセスの XNUMX つがシステムのリソースを過剰に消費していることがわかった場合、できることは XNUMX つあります。
1. プロセスを中断せずに、プロセスの使用リソースを削減します。
2. プロセスを完全に停止します。
プロセスを実行し続けたいが、システム上の他のプロセスにもチャンスを与えたい場合は、次のようにすることができます。 renice プロセス。 の使用とは別に、 nice or renice コマンド、 top 問題のあるプロセスを特定し、優先順位を下げる簡単な方法です。
「NI」列でプロセスを特定します。そのプロセスには負の優先順位が設定されている可能性が高くなります。 タイプ r をクリックし、削除するプロセスのプロセス ID を入力します。 次に、適切な値、たとえば「20」を入力します。 つまり、今後、このプロセスには最大で CPU サイクルの 1/5 がかかることになります。
実行し続けたいプロセスの例としては、エミュレーター、仮想マシン、コンパイラーなどが挙げられます。
プロセスがハングしたり、I/O 消費、ファイル作成、その他のシステム リソースの使用によって完全に暴走したためにプロセスを停止したい場合は、 kill 指示。 機会があれば、まずプロセスをソフトに強制終了して、プロセスに シグターム 信号。 これは、プログラムのコードに記述されている手順に従って、実行中の処理を終了する命令です。
ジョー:~> ps-ef | grep モジラ
ジョー 25822 1 0 11 月 XNUMX 日 ?
00:34:04 /usr/lib/mozilla-1.4.1/mozilla-
ジョー:~> ps-ef | grep モジラ
ジョー 25822 1 0 11 月 XNUMX 日 ?
ジョー:~> キル -15 25822
ジョー:~> キル -15 25822
上の例では、ユーザー ジョー Mozilla ブラウザがハングしたため停止しました。
一部のプロセスは削除するのが少し困難です。 時間があれば、SIGINT シグナルを送信して中断するとよいでしょう。 これでも問題が解決しない場合は、最も強力なシグナル SIGKILL を使用してください。 以下の例では、 ジョー フリーズした Mozilla を停止します。
ジョー:~> ps-ef | grep モジラ
ジョー 25915 1 0 11 月 XNUMX 日 ?
00:15:06 /usr/lib/mozilla-1.4.1/mozilla-
ジョー:~> ps-ef | grep モジラ
ジョー 25915 1 0 11 月 XNUMX 日 ?
ジョー:~> キル -9 25915
ジョー:~> ps-ef | grep 25915
ジョー 2634 32273 0 18:09 ポイント/4 00:00:00 grep 25915
ジョー:~> キル -9 25915
ジョー:~> ps-ef | grep 25915
ジョー 2634 32273 0 18:09 ポイント/4 00:00:00 grep 25915
このような場合は、次のコマンドを使用して、プロセスが本当に停止しているかどうかを確認するとよいでしょう。 grep PID で再度フィルタリングします。 これだけが返される場合は、 grep プロセスを停止できたことを確認できます。
強制終了するのが難しいプロセスの XNUMX つはシェルです。 それは良いことです。もし簡単に殺せるとしたら、入力するたびに殻を破るでしょう。 Ctrlキー-C これは SIGINT を送信するのと同じであるため、コマンドラインで誤って実行してしまいます。
あるコマンドの出力を別のコマンドの入力として使用するためのパイプ (|) の使用法については、次の第 5 章で説明します。