Linux パフォーマンスの監視とチューニングの概要

これは、Linux パフォーマンスの監視とチューニングに関する新しいシリーズの最初の記事です。

Linux システム管理者は、Linux のパフォーマンスの監視とチューニングに習熟している必要があります。この記事では、Linux でパフォーマンスの監視とチューニングにどのように取り組むべきか、および監視する必要があるさまざまなサブシステム (およびパフォーマンスメトリック) についての概要を説明します。

システムのボトルネックを特定し、それを修正するソリューションを考え出すには、Linux のさまざまなコンポーネントがどのように機能するかを理解する必要があります。たとえば、カーネルがナイス値を使用して他の Linux プロセスよりも 1 つの Linux プロセスを優先する方法、I/O 割り込みの処理方法、メモリ管理の仕組み、Linux ファイルシステムの仕組み、Linux でのネットワーク層の実装方法などです。、

さまざまなコンポーネント (またはサブシステム) がどのように機能するかを理解することは、特定の出力を得るために実行するコマンドを理解することと同じではないことに注意してください。たとえば、「uptime」または「top」コマンドで「負荷平均」が得られることをご存知かもしれません。しかし、それが何を意味するのか、CPU (またはプロセス) サブシステムがどのように機能するのかを知らなければ、正しく理解できない可能性があります。サブシステムを理解することは進行中のタスクであり、常に学習し続ける必要があります。

非常に大まかに言うと、次の 4 つのサブシステムを監視する必要があります。

CPU
記憶
I/O
ネットワーク

1. CPU

CPU の 4 つの重要なパフォーマンスメトリック (コンテキストスイッチ、実行キュー、CPU 使用率、負荷平均) を理解する必要があります。

コンテキストスイッチ

CPU があるプロセス (またはスレッド) から別のプロセスに切り替わることは、コンテキストスイッチと呼ばれます。
プロセスの切り替えが発生すると、カーネルは (プロセスまたはスレッドの) CPU の現在の状態をメモリに保存します。
また、カーネルは以前に保存された (プロセスまたはスレッドの) 状態をメモリから取得し、CPU に格納します。
CPU のマルチタスクには、コンテキストの切り替えが非常に重要です。
ただし、コンテキスト切り替えのレベルが高いと、パフォーマンスの問題が発生する可能性があります。

実行キュー

実行キューは、CPU の現在のキューにあるアクティブなプロセスの総数を示します。
CPU がプロセスを実行する準備ができると、プロセスの優先度に基づいて実行キューからプロセスを取得します。
スリープ状態または I/O 待機状態のプロセスは実行キューにないことに注意してください。
したがって、実行キュー内のプロセス数が多いと、パフォーマンスの問題が発生する可能性があります。

CPU 使用率

これは、現在使用されている CPU の量を示します。
これはかなり単純明快で、top コマンドから CPU 使用率を表示できます。
100% の CPU 使用率は、システムが完全にロードされていることを意味します
そのため、CPU 使用率の割合が高くなると、パフォーマンスの問題が発生します。

負荷平均

これは、特定の期間の平均 CPU 負荷を示します。
Linux では、過去 1 分間、5 分間、および 15 分間の負荷平均が表示されます。これは、システム全体の負荷が上がっているか下がっているかを確認するのに役立ちます。
たとえば、「0.75 1.70 2.10」の負荷平均は、システムの負荷が低下していることを示します。 0.75 は、過去 1 分間の負荷平均です。 1.70 は、過去 5 分間の負荷平均です。 2.10 は、過去 15 分間の負荷平均です。
この負荷平均は、キュー内のプロセスの総数と、中断不可能なタスクステータスのプロセスの総数の両方を組み合わせて計算されることに注意してください。

2.ネットワーク

TCP/IP の概念をよく理解していると、ネットワークの問題を分析する際に役立ちます。これについては、今後の記事で詳しく説明します。
ネットワークインターフェースについては、インターフェースを介して送受信されたパケット (およびバイト) の総数、ドロップされたパケットの数などを監視する必要があります。

3.入出力

I/O 待機は、CPU が I/O を待機している時間です。システムで I/O 待機が一貫して高い場合は、ディスクサブシステムに問題があることを示しています。
1 秒あたりの読み取り数と 1 秒あたりの書き込み数も監視する必要があります。これはブロック単位で測定されます。つまり、1 秒あたりの読み取り/書き込みブロック数です。これらは、bi および bo (ブロックインおよびブロックアウト) とも呼ばれます。
tps は、rtps (1 秒あたりの読み取りトランザクション) と wtps (1 秒あたりの書き込みトランザクション) の合計である、1 秒あたりの合計トランザクションを示します。

4.メモリ

ご存じのとおり、RAM は物理メモリです。システムに 4 GB の RAM がインストールされている場合、物理メモリは 4 GB になります。
仮想メモリ =ディスクで利用可能なスワップ領域 + 物理メモリ。仮想メモリには、ユーザー空間とカーネル空間の両方が含まれます。
32 ビットシステムと 64 ビットシステムのどちらを使用するかによって、プロセスが使用できるメモリの量を決定する際に大きな違いが生じます。
32 ビットシステムでは、プロセスは最大 4GB の仮想メモリにしかアクセスできません。 64 ビットシステムでは、このような制限はありません。
未使用の RAM は、カーネルによってファイルシステムキャッシュとして使用されます。
Linux システムは、より多くのメモリが必要になるとスワップします。つまり、物理メモリよりも多くのメモリが必要な場合です。スワップするとき、物理メモリからディスク上のスワップ領域に最も使用されていないメモリページを書き込みます。
ディスクは物理メモリよりもはるかに低速であり、メモリページを RAM からディスクにスワップするには時間がかかるため、多くのスワップがパフォーマンスの問題を引き起こす可能性があります。

上記の 4 つのサブシステムはすべて相互に関連しています。 1 秒あたりの読み取り数、1 秒あたりの書き込み数、または I/O 待機が高いからといって、I/O サブシステムに問題があるとは限りません。また、アプリケーションが何をしているかによっても異なります。ほとんどの場合、パフォーマンスの問題は、Linux システムで実行されているアプリケーションが原因である可能性があります。

80 対 20 のルールを覚えておいてください。パフォーマンスの向上の 80% はアプリケーションの調整によってもたらされ、残りの 20% はインフラストラクチャコンポーネントの調整によってもたらされます。

Linux システムのパフォーマンスを監視するために利用できるさまざまなツールがあります。例:top、free、ps、iostat、vmstat、mpstat、sar、tcpump、netstat、iozone など。このシリーズの今後の記事で、これらのツールとその使用方法について詳しく説明します。

以下は、パフォーマンスの問題を特定して解決するための 4 つのステップのアプローチです。

ステップ 1 – 問題を理解 (および再現) する: 問題が何であるかを明確に理解すれば、問題の半分は解決されます。パフォーマンスの問題を解決する前に、まず問題を明確に定義してください。問題の理解と定義に時間を費やすほど、適切な場所で答えを探すのに十分な詳細が得られます。可能であれば、問題の再現を試みるか、少なくとも問題によく似ていると思われる状況をシミュレートしてください。これは、パフォーマンスの問題を解決するために考え出したソリューションを後で検証するのに役立ちます。
ステップ 2 – データの監視と収集: 問題を明確に定義した後、システムを監視し、さまざまなサブシステムでできるだけ多くのデータを収集してみてください。このデータに基づいて、潜在的な問題のリストを作成します。
ステップ 3 – 問題を排除して絞り込む: 潜在的な問題のリストを作成したら、それらのそれぞれに飛び込んで、問題のないものを排除します。さらに絞り込んで、アプリケーションの問題なのか、インフラストラクチャの問題なのかを確認します。さらに掘り下げて、特定のコンポーネントに絞り込みます。たとえば、インフラストラクチャの問題の場合は、問題を絞り込んで、問題の原因となっているサブシステムを特定します。 I/O サブシステムの問題である場合は、特定のパーティション、RAID グループ、LUN、またはディスクに絞り込みます。基本的には、問題の根本原因を突き止めるまでドリルダウンを続けてください。
ステップ 4 – 一度に 1 つずつ変更: 潜在的な問題の小さなリストに絞り込んだら、一度に複数の変更を加えようとしないでください。複数の変更を行った場合、元の問題を修正したのはどれかわかりません。一度に複数の変更を行うと、新しい問題が発生する可能性があり、元の問題を修正する代わりに追跡することになります。そのため、一度に 1 つの変更を加えて、元の問題が解決するかどうかを確認してください。

パフォーマンスシリーズの今後の記事では、さまざまな Linux パフォーマンス監視ツールを使用して、CPU、メモリ、I/O、およびネットワークサブシステムのパフォーマンスの問題を監視し、対処する方法について詳しく説明します。