Linuxサーバーのパフォーマンスパラメータ

Linux オペレーティング システムに基づくサーバーが実行されている場合、さまざまなパラメーター情報も表示されます。一般に、運用および保守担当者やシステム管理者はこのデータに非常に敏感ですが、これらのパラメータは開発者にとっても非常に重要であり、特にプログラムが正常に動作しない場合、これらの手がかりは問題を迅速に特定して追跡するのに役立つことがよくあります。

ここでは、システムの関連パラメーターを表示するための簡単なツールをいくつか紹介します。もちろん、多くのツールは、/proc および /sys のデータを分析および処理することによっても機能します。また、より詳細で専門的なパフォーマンスの監視や、チューニングを完了するには、より専門的なツール (perf、systemtap など) やテクノロジーが必要になる場合もあります。結局のところ、システムパフォーマンス監視自体は大学の科目です。

1. CPU およびメモリ カテゴリ

1.1 トップ

➜ ~ トップ

最初の行の後の 3 つの値は、過去 1 年、5 年、および 15 年間のシステムの平均負荷です。負荷には上昇、安定、下降の傾向があり、この値がCPU実行可能ユニット数を超えた場合、CPUの性能が飽和してボトルネックになっていると考えられます。

2 行目は、システムのタスク ステータス情報をカウントします。言うまでもなく、実行には、CPU 上で実行されているタスクと実行がスケジュールされているタスクが含まれます。スリープは通常、イベント (IO 操作など) が完了するのを待っているタスクであり、細分化には割り込み可能なタイプと割り込み不可能なタイプが含まれます。停止とは、一時停止されているものです タスクは通常、SIGSTOP を送信するか、フォアグラウンド タスク上で Ctrl-Z を操作して一時停止します。ゾンビ タスクは、プロセスが終了するとリソースが自動的にリサイクルされますが、終了タスクを含むタスク記述子には、親プロセスが解放される前にこのようなプロセス 親プロセスが早期に終了したり、wait をコールしなかったりしたため、無効状態として表示される このようなプロセスが発生した場合は、プログラムの設計が間違っていないか特に注意する必要があります。 CPU 使用率の 3 行目は、タイプに応じて次の状況を示します。

## ● (us) user: 低い nice 値 (高優先度) ユーザー モード (nice#● (sy) システム: カーネル モードで CPU が費やした時間。オペレーティング システム コール (システム コール) は、特定のサービスを実行するためにユーザー モードからカーネル状態に入ります。通常、値は小さくなりますが、サーバーによって実行される IO が比較的集中的である場合、値は大きくなります

● (ni ) Nice: 高いnice値(低優先度)のユーザーモードで低優先度で実行されているCPUによって費やされた時間(nice>0)。デフォルトでは、新しく開始されたプロセス nice=0 は、renice または setpriority() を通じてプログラムの nice 値を手動で変更しない限り、ここには含まれません。

#●(id) idle: CPU はアイドル状態 (実行中)カーネル アイドル ハンドラーによって占有された時間

#● (wa) iowait: IO の完了を待機する占有時間

##● (hi) irq: システムのハードウェア割り込み処理によって消費された時間

● (si)softirq: システムがsoftirqsを処理するのにかかる時間。softirqsはsoftirqs、タスクレット(実際には前者の特殊なケース)、ワークキューに分かれていることを覚えておいてください。どのような時間がカウントされるのかはわかりません。キューの実行はもはや割り込みコンテキストではありません

●(st) スチール: 仮想マシンの場合は、仮想マシン配下の CPU も共有するため、これは意味があります。したがって、この期間は、仮想マシンがハイパーバイザー スケジュールの CPU 時間を待っていることを示します。また、ハイパーバイザーがこの期間中に CPU を他の CPU に実行するようにスケジュールし、この期間の CPU リソースが「盗まれた」ことを意味します。この値は、私の KVM VPS マシンでは 0 ではありませんが、0.1 程度にすぎません。VPS がオーバーブッキングされているかどうかを判断するために使用できますか?

高い CPU 占有率には何らかの意味があることがよくあります。これは、サーバーの CPU 使用率が高すぎる場合の、対応するトラブルシューティングのアイデアも示しています:

1. ユーザーの占有率が高すぎる場合、現時点では、通常、CPU を大量に占有する個別のプロセスであるため、top からプログラムを見つけるのは簡単ですが、この時点でプログラムが異常であると思われる場合は、perf などを使用してプログラムを見つけることができます。詳細な調査のためのホット コール機能;

2. システム占有率が高すぎる場合、IO 操作 (端末 IO を含む) が多い場合、CPU 占有率のこの部分が高くなる可能性があります。ファイル サーバー、データベース サーバー、およびその他のタイプのサーバー、それ以外の場合 (たとえば、>20%) カーネルお​​よびドライバー モジュールの一部に問題がある可能性が非常に高くなります;

3. 良好な占有率が以下の場合プロセスの開始者が、一部のプロセスが高いレベルの CPU を占有していることを認識している場合、他のプロセスの CPU 使用要求が殺到しないように、その nice 値が設定されます。 ##

4. iowait 占有率が高すぎる場合は、通常、一部のプログラムの IO 処理効率が非常に低いか、IO 対応デバイスのパフォーマンスが非常に低いため読み取りおよび書き込み処理に時間がかかることを意味します。 to complete;

5. irq/softirq 占有率が高すぎる場合は、一部の周辺機器に問題があり、大量の irq リクエストが発生している可能性があります。 proc/interrupts ファイルを使用して問題を特定する;

6. 盗用占有率が高すぎると、悪徳メーカーの仮想マシンが売り過ぎています。

4 行目と 5 行目は、物理メモリと仮想メモリ (スワップ パーティション) の情報です: total = free used buff/cache. ここで、バッファとキャッシュされた Mem 情報は合計されますが、バッファとキャッシュ

メムの関係は多くの場所で明らかにされていません。実際、データを比較すると、これら 2 つの値は /proc/meminfo の Buffers フィールドと Cached フィールドです。 Buffers は RAW ディスクのブロック キャッシュであり、主にファイル システムのメタデータ (スーパー ブロック情報など) をキャッシュします。 、など）を raw ブロックの形式で保存します。この値は一般に比較的小さい (約 20M)。Cached は、ファイル アクセス効率を向上させるために、特定のファイルを読み取ってキャッシュするために使用されます。ファイル キャッシュに使用されると言えます。ファイルシステム。

そして、avail Mem は新しいパラメータ値で、スワップなしで新しく開かれたプログラムにどれだけのメモリ空間を与えることができるかを示すために使用されます。これは、free buff/cached とほぼ同等であり、これも、上記のステートメントでは、キャッシュされた空きバッファー Mem は実際に利用可能な物理メモリです。さらに、スワップ パーティションの使用は必ずしも悪いことではないため、スワップ パーティションの使用量は重大なパラメータではありませんが、頻繁なスワップ イン/アウトは良いことではありません。この状況は注意が必要であり、通常は物理メモリの不足を示します。

最後に、各プログラムのリソース使用量のリストを示します。CPU 使用量は、すべての CPU コアの使用量の合計です。通常、top が実行されると、プログラム自体が多数の /proc 操作を読み取るため、基本的には top プログラム自体が最高のものになります。

top は非常に強力ですが、通常はコンソール上でシステム情報をリアルタイムに監視するために使用され、長期間 (数日、数ヶ月) のシステム負荷情報を監視するのには適していません。時間の短いプロセスも見逃されるため、提供できなくなります。統計を出力します。

1.2 vmstat

vmstat は、top 以外によく使用されるシステム検出ツールです。下のスクリーンショットは、-j4 を指定して boost をコンパイルしたときのシステム負荷です。

r は実行可能なプロセスの数を表し、データはほぼ一致しています。b は中断できないスリープ プロセスの数を表します。swpd は使用されている仮想メモリの量を表します。 top-Swap と一致します -used の値には意味があり、マニュアルにあるように、通常、バッファの数はキャッシュされた Mem よりもはるかに小さいです。バッファは通常 20M 程度です。io フィールドの bi と bo は、 1 秒あたりにディスクに送受信されるデータの数、ブロック数 (ブロック/秒)、システム フィールドの in は 1 秒あたりのシステム割り込みの数 (クロック割り込みを含む) を示し、cs はコンテキスト スイッチの数を示します。プロセスの切り替え。

そういえば、Linux カーネルをコンパイルするときに -j パラメータを CPU Core にするか CPU Core 1 にするかで悩んだ人も多いのではないでしょうか？上記の -j パラメーター値を変更し、vmstat モニタリングをオンにしてブーストおよび Linux カーネルをコンパイルすると、どちらの場合でもコンテキスト スイッチは基本的に変化せず、-j 値を大幅に増加した場合にのみコンテキスト スイッチが大幅に増加することがわかりました。具体的なコンパイル時間はまだテストしていませんが、このパラメータにこだわりすぎるのは不必要だと思われます。この情報によると、システムの起動状態またはベンチマーク状態にない場合は、パラメータ コンテキスト スイッチが 100000 を超えるプログラムに何か問題があるはずです。

1.3 pidstat

特定のプロセスの包括的かつ詳細な追跡を実行したい場合、pidstat ほど適したものはありません。スタック領域、ページ欠落状態、アクティブおよびパッシブの切り替え、その他の情報が記録されます。採取した眼底。このコマンドの最も便利なパラメータは -t で、プロセス内の各スレッドに関する詳細情報を一覧表示できます。

-r: ページ フォールトとメモリ使用量を表示します。ページ フォールトは、プログラムが仮想メモリ空​​間にマップされているが物理メモリにまだロードされていないページにアクセスする必要がある場合に発生します。メイン ページは 2 つあります。障害。タイプは

minflt/s で、軽度の障害を指します。アクセスする必要がある物理ページが、何らかの理由 (共有ページ、キャッシュ メカニズムなど) で物理メモリに既に存在する場合です。 )、現在のプロセスのページ テーブル内にのみ存在します。MMU には参照がありません。MMU は対応するエントリを設定するだけで済みます。コストは非常に小さいです。

majflt/s はメジャーを参照しますMMU は、現在利用可能な物理メモリ内の空き物理ページを申請する必要があります (利用可能な空きページがない場合は、他の物理ページをスワップ領域に切り替えて空き物理ページを解放する必要があります)。外部から物理ページにアクセスし、対応するエントリを設定します。このコストは非常に高くなります。以前の

#-s とはデータ レベルでいくつかの違いがあります。スタック使用量 (スレッド用に予約されたスタック スペースを含む) StkSize、および StkRef によって実際に使用されるスタック領域。 ulimit -s を使用すると、CentOS 6.x のデフォルトのスタック スペース サイズが 10240K であるのに対し、CentOS 7.x および Ubuntu シリーズのデフォルトのスタック スペース サイズは 8196K

であることがわかります。

-u: CPU 使用率。パラメータは前のパラメータと同様です。

-w: スレッド コンテキスト スイッチの数。これも cswch/s に細分されます。リソース待ちなど。要因によるアクティブな切り替えとnvcswch/sスレッドのCPU時間によるパッシブな切り替えの統計

毎回psでプログラムのpidを取得してからだと非常に面倒です。 pidstat を操作するので、これがキラーです -C 特定の文字列を指定でき、コマンドにこの文字列が含まれている場合、プログラム情報が表示され、カウントされます -l 完全なプログラム名とパラメーターを表示できます ➜ ~ pidstat -w - t -C "ailaw" - l

単一のタスク、特にマルチスレッドのタスクを表示する場合、一般的に使用される ps よりも pidstat の方が優れているようです。

1.4 その他

単一の CPU の状況を個別に監視する必要がある場合は、htop に加えて、mpstat を使用して SMP プロセッサ上の各コアのワークロードが低下しているかどうかを確認することもできます。ロード バランシングと、特定のホットスポット スレッドがコアを占有しているかどうか。 ➜ ~ mpstat -P ALL 1

特定のプロセスによって占有されているリソースを直接監視したい場合は、top -u taozj を使用して他のユーザーに依存しないプロセスを除外するか、次の方法を使用できます。 ps コマンドは、出力する必要があるエントリ情報をカスタマイズできます:

while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1;ned

継承関係を明確にしたい場合は、以下の一般的に使用されるパラメータを使用してプロセス ツリー構造を表示できます。表示効果は pstree

よりもはるかに詳細で美しいです。 ➜ ~ ps axjf

II 、ディスク IO クラス

iotop は、各プロセスおよびスレッドのリアルタイムのディスク読み取り速度を直感的に表示できます。lsof は、通常のファイル (ユーザー) のオープン情報だけでなく、/dev/sda1 の操作も行います。この種のデバイス ファイルのオープン情報は、たとえば、パーティションがアンマウントできない場合に、lsof を使用してディスク パーティションの使用状況を確認できます。 fgパラメータを追加すると、ファイルオープンフラグマークを追加表示することもできます。

2.1 iostat

➜ ~ iostat -xz 1

実際、iostat -xz 1 または sar -d 1 のどちらを使用する場合でも、ディスクの重要なパラメーターは次のとおりです。

avgqu-s: デバイスに送信される I/O リクエストの待機キューの平均長さ。単一ディスクの場合、値 > 1 はデバイスが飽和状態であることを示します (複数のディスクを備えた論理ディスクを除く)

await( r_await, w_await): リクエストがキューに入れられて処理されるまでの時間の合計を含む、各デバイス I/O リクエスト操作の平均待機時間 (ミリ秒);

svctm: デバイス I/O リクエストに送信される平均サービス時間 (ミリ秒)。svctm が await に非常に近い場合、待機している I/O がほとんどなく、ディスク パフォーマンスが非常に良好であることを意味します。それ以外の場合、ディスク キュー待ち時間が長く、ディスクの応答が悪い;

%util: デバイスの使用状況は、1 秒あたりの I/O 作業時間の割合を示します。%util>60% の場合、単一ディスクのパフォーマンス(await の増加に反映されます) 100% に近づくと、デバイスのパフォーマンスが低下します。飽和 (複数のディスク アレイを持つ論理ディスクを除く);

また、監視対象のディスクであっても、パフォーマンスが比較的低いため、必ずしもアプリケーションの応答に影響を与えるわけではありません。カーネルは通常、パフォーマンスを向上させるために I/O 非同期テクノロジを使用し、読み取り/書き込みキャッシュ テクノロジを使用してパフォーマンスを向上させますが、これは上記の物理メモリの制限によって制限されます。

上記のパラメータはネットワーク ファイル システムにも適用できます。

3. ネットワーク カテゴリ

サーバーにとってネットワーク パフォーマンスの重要性は自明のことであり、iptraf ツールはネットワークの送受信速度情報を直感的に表示できます。同様のスループット情報は sar -n DEV 1 からも取得でき、100M ネットワーク カードやギガビット ネットワーク カードなどのネットワーク カードには最大レート情報が標準で搭載されているため、比較が簡単です。デバイスの使用率を確認します。

通常、ネットワーク開発において最も重要な関心事はネットワーク カードの伝送速度ではなく、特定の UDP および TCP 接続のパケット損失率、再送信率、ネットワーク遅延、その他の情報です。

3.1 netstat

➜ ~ netstat -s

システム起動以降の各プロトコルの全体的なデータ情報を表示します。パラメータ情報は比較的豊富で便利ですが、2 回の実行の差分を使用して現在のシステムのネットワーク状態情報を取得するか、時計を使用して数値変化の傾向を視覚化するまで累積値を取得できません。したがって、通常、netstat はポートと接続情報の検出に使用されます:

netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)

–タイマーはドメイン名の逆クエリをキャンセルし、表示速度を高速化できます。より一般的に使用されるものは

です。 ➜ ~ netstat -antp #list すべての TCP 接続

➜ ~ netstat -nltp #すべてのローカル TCP リスニング ソケットをリストします。-a パラメータは追加しないでください

3.2 sar

sar このツールは非常に強力なので、CPU からディスク、ページ交換まですべてを制御できます。ここで使用される -n は、主にネットワーク アクティビティを分析するために使用されます。ただし、ネットワークは、さまざまなレベルでさまざまなプロトコルのデータも分解します。 NFS、IP、ICMP、SOCK など、情報としては、TCP と UDP のみを考慮します。次のコマンドには、通常のセグメントおよびデータグラムの送受信ステータスを表示するだけでなく、

TCP ➜ ~ sudo sar -n TCP,ETCP 1

も含まれています。 #

active/s: connect() などを介してローカルで開始された TCP 接続、TCP ステータスが CLOSED -> SYN-SENT に変更されます

passive/s: accept などを介してリモートで開始された TCP 接続()、TCP ステータスの変化は LISTEN -> SYN-RCVD

retrans/s(tcpRetransSegs): 1 秒あたりの TCP 再送信数。通常、ネットワーク品質が低いか、サーバーが過負荷でパケットが、TCP の確認再送信メカニズムに従って再送信操作が発生します

isegerr/s(tcpInErrs): エラー データ パケットが 1 秒ごとに受信されます (チェックサムの失敗など)

UDP ➜ ~ sudo sar -n UDP 1

noport/s(udpNoPorts): 1 秒あたりに受信されたが、指定された宛先ポートにアプリケーションが存在しないデータグラムの数

idgmerr/s(udpInErrors) : データグラムの数受信したが、上記の理由を除き、マシンによって配信できない

もちろん、これらのデータはネットワークの信頼性をある程度示すことができますが、特定のビジネス需要のシナリオとのみ組み合わせることができます。これには意味があります。

3.3 tcpdump

tcpdump は良いものだと言わざるを得ません。ローカルでデバッグするときに Wireshark を使用するのが好きなことは誰もが知っていますが、オンライン サーバーに問題がある場合はどうすればよいでしょうか?

付録のリファレンスでは、環境を復元し、tcpdump を使用してパケットをキャプチャします。問題が再発する場合 (ログの表示や特定のステータスが表示されるなど)、パケット キャプチャを終了して、tcpdump を実行することができます。キャプチャされたパケットの保存ファイルのサイズを制限できる -C/-W パラメータがあり、この制限に達すると、保存されたパケット データが自動的にローテーションされるため、キャプチャされたパケットの全体数を制御できます。その後、データ パケットを回線から取り出し、Wireshark を使用して好きなように表示できます。 tcpdump には GUI インターフェイスはありませんが、パケット キャプチャ機能はまったく弱いわけではなく、ネットワーク カード、ホスト、ポート、プロトコルなどのさまざまなフィルタリング パラメータを指定できます。オンライン プログラムの分析も非常に簡単です。

次は小さなテストです。Chrome が起動時に Web サーバーへの 3 つの接続の確立を自動的に開始することがわかります。ここでは dst ポート パラメータが制限されているため、サーバーの応答パケットはフィルターで除外されます。それを削除して、Wireshark で開きます。SYNC と ACK を介して接続を確立するプロセスは、依然として非常に明白です。 tcpdump を使用する場合は、キャプチャ フィルターの条件を可能な限り設定する必要があります。これにより、その後の分析が容易になる一方で、tcpdump をオンにした後、ネットワーク カードやシステムのパフォーマンスに影響を及ぼし、これはオンライン サービスのパフォーマンスに影響を与えます。

その他の Linux 記事については、Linux チュートリアル 列にアクセスして学習してください。

以上がLinuxサーバーのパフォーマンスパラメータの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。