Linuxのパフォーマンスチューニング~

Linux オペレーティング システムはオープン ソース製品であり、オープン ソース ソフトウェアの実践およびアプリケーション プラットフォームでもあります。このプラットフォームでは、Apache、Tomcat、mysql、php など、無数のオープン ソース ソフトウェアがサポートされています。オープンソース ソフトウェアの最大のコンセプトは、自由とオープンさです。したがって、オープン ソース プラットフォームとしての Linux の目標は、これらのオープン ソース ソフトウェアのサポートを通じて、最小限のコストで最適なアプリケーション パフォーマンスを実現することです。パフォーマンスの問題に関して言えば、主に達成されるのは、Linux オペレーティング システムとアプリケーションの最適な組み合わせです。

1. パフォーマンスの問題の概要

システム パフォーマンスとは、タスクを完了する際のオペレーティング システムの有効性、安定性、応答速度を指します。 Linux のシステム管理者は、Linux 上で Web サービスを構築する際に、Web ページが開けない、開く速度が遅いなど、システムが不安定になったり、応答速度が遅いなどの問題に遭遇することがあります。 Linux システムが良くないのは、実際には表面的なものです。オペレーティング システムがタスクを完了するときは、システム自体の設定、ネットワーク トポロジ、ルーティング機器、ルーティング ポリシー、アクセス機器、物理回線などの側面と密接に関係しており、リンクに問題があるとシステム全体のパフォーマンスに影響します。そのため、Linuxアプリケーションで問題が発生した場合には、アプリケーションプログラム、OS、サーバーハードウェア、ネットワーク環境などから総合的に調査を行い、問題が発生している箇所を特定し、一元的に解決する必要があります。

アプリケーション、オペレーティング システム、サーバー ハードウェア、ネットワーク環境などに関して、パフォーマンスに最も大きな影響を与える 2 つの側面は、アプリケーション プログラムとオペレーティング システムです。これら 2 つの側面の問題は検出が難しく、高度に隠蔽されています。ハードウェアまたはネットワークに問題がある限り、通常はすぐに原因を特定できます。以下では、主にオペレーティング システムのパフォーマンス チューニングのアイデアについて説明しますが、アプリケーションの特定の問題については詳細に対処する必要があります。

以下では、Linux のパフォーマンスに影響を与える要因、パフォーマンスの分析に携わる人々、システム パフォーマンス最適化ツール、システム パフォーマンスの評価基準の 4 つの側面から Linux を最適化するための一般的な考え方と方法を紹介します。

2. Linux のパフォーマンスに影響を与える要因

2.1 システムハードウェアリソース

＃＃＃１。 CPU＃＃＃

CPU は、オペレーティング システムの安定した動作の基盤です。CPU の速度とパフォーマンスは、システム全体のパフォーマンスを大きく左右します。したがって、CPU の数が多く、メイン周波数が高いほど、パフォーマンスは向上します。サーバーのパフォーマンスになります。しかし、それは完全に真実ではありません。

現在、ほとんどの CPU は同時に 1 つのスレッドしか実行できません。ハイパースレッド プロセッサは同時に複数のスレッドを実行できます。したがって、プロセッサのハイパー スレッディング機能を使用してシステム パフォーマンスを向上させることができます。 Linux システムでは、ハイパー スレッディングは SMP カーネルを実行している場合にのみサポートされますが、インストールする CPU の数が増えるほど、ハイパー スレッディングから得られるパフォーマンスの向上は少なくなります。さらに、Linux カーネルはマルチコア プロセッサを複数の個別の CPU として認識します。たとえば、Lnux システムでは 2 つの 4 コア CPU は 8 つのシングルコア CPU として認識されます。ただし、パフォーマンスの観点から見ると、2 つの 4 コア CPU と 8 つのシングルコア CPU は完全に同等ではなく、権威ある部門によるテスト結果によれば、前者の全体的なパフォーマンスは後者より 25% ～ 30% 低いとされています。

CPU ボトルネックが発生する可能性のあるアプリケーションには、DB サーバー、動的 Web サーバーなどが含まれます。このようなアプリケーションでは、CPU 構成とパフォーマンスを優先する必要があります。

＃＃＃２。メモリ＃＃＃

メモリのサイズも、Linux のパフォーマンスに影響を与える重要な要素です。メモリが小さすぎると、システム プロセスがブロックされ、アプリケーションが遅くなったり、応答しなくなったりします。メモリが大きすぎると、リソースが無駄になります。 Linux システムでは、物理メモリと仮想メモリの 2 つの方式が使用されており、仮想メモリを使用すると物理メモリの不足を軽減できますが、仮想メモリを占有しすぎるとアプリケーションのパフォーマンスが大幅に低下します。アプリケーションの物理メモリ 十分な大きさが必要ですが、物理メモリが大きすぎるとメモリ リソースが無駄になります。たとえば、32 ビット プロセッサを搭載した Linux オペレーティング システムでは、8GB を超える物理メモリが無駄になります。したがって、より大きなメモリを使用するには、64 ビット オペレーティング システムをインストールし、Linux の大メモリ カーネル サポートを有効にすることをお勧めします。

プロセッサのアドレス範囲の制限により、32 ビット Linux オペレーティング システムでは、単一のアプリケーション プロセスは最大 4GB のメモリしか使用できません。このようにして、システムのメモリが大きい場合でも、アプリケーションははい、解決策は 64 ビット プロセッサを使用し、64 ビット オペレーティング システムをインストールすることです。 64 ビット オペレーティング システムでは、すべてのアプリケーションのメモリ使用量のニーズをほとんど制限なく満たすことができます。

メモリ パフォーマンスのボトルネックが発生する可能性のあるアプリケーションには、NOSQL サーバー、データベース サーバー、キャッシュ サーバーなどが含まれます。このようなアプリケーションでは、メモリ サイズを優先する必要があります。

＃＃＃＃３．ディスク I/O パフォーマンス

ディスクのI/O性能はアプリケーションの性能に直接影響を与えるため、頻繁に読み書きを行うアプリケーションでは、ディスクのI/O性能が満たされないとアプリケーションが停滞してしまいます。幸いなことに、今日のディスクでは、一般的なディスク RAID テクノロジなど、I/O パフォーマンスを向上させるために多くの方法が使用されています。

RAID テクノロジーによって形成されるディスク グループは、大容量のハードディスクに相当します。ユーザーはその上でパーティションのフォーマットやファイル システムの作成などの操作を実行できます。単一の物理ハードディスクとまったく同じです。唯一の違いは I/O です。 RAID ディスク グループのパフォーマンス比が向上し、単一ハード ドライブのパフォーマンスが大幅に向上し、データ セキュリティも大幅に向上します。

さまざまなディスクの組み合わせ方法に応じて、RAID は RAID0、RAID1、RAID2、RAID3、RAID4、RAID5、RAID6、RAID7、RAID0 1、RAID10 などのレベルに分類できます。一般的に使用される RAID レベルは、RAID0、RAID1、RAID5、 RAID0 1. について簡単に紹介します。

#「

」

RAID 0

: 複数のハード ドライブを大容量のハード ドライブ グループに結合することで、ディスクのパフォーマンスとスループットが向上します。この方法は低コストであり、少なくとも 2 つのディスクが必要ですが、耐障害性やデータ回復機能がないため、高いデータ セキュリティが要求されない環境でのみ使用できます。 RAID 1
: つまり、ディスクミラーリングです。あるディスクのデータを別のディスクにミラーリングすることで、ディスクデータの信頼性と修復性を最大限に高め、高いデータ冗長性を実現します。容量には余裕がありますが、ディスク使用率は 50% しかないため、最もコストが高く、重要なデータを保存する場合に主に使用されます。 RAID5
: ディスク セグメンテーションとパリティ チェック テクノロジを使用してシステムの信頼性を向上します。RAID5 は読み取り効率と平均書き込み効率が高く、少なくとも 3 つのディスクが必要です。データの可用性に影響を与えることなく、ディスクに障害が発生しても許容します。 RAID0 1
: RAID0 と RAID1 テクノロジーを組み合わせると RAID0 1 となり、少なくとも 4 台のハード ドライブが必要になります。この方法ではデータが複数のディスクに分散されることに加えて、各ディスクには独自のミラー ディスクがあり、完全な冗長性が提供され、データの可用性に影響を与えることなく 1 つのディスク障害が発生しても許容され、高速な読み取り/書き込み機能が備わっています。

」

#各 RAID レベルのパフォーマンスを理解することで、アプリケーションのさまざまな特性に基づいて適切な RAID レベルを選択でき、アプリケーションが最適なディスク パフォーマンスを実現できるようになります。

＃＃＃４．インターネットブロードバンド

Linux 上のさまざまなアプリケーションは一般にネットワークに基づいているため、ネットワーク帯域幅もパフォーマンスに影響を与える重要な要素です。低速で不安定なネットワークではネットワーク アプリケーションへのアクセスがブロックされますが、安定した高速ネットワークではネットワーク アプリケーションへのアクセスがブロックされます。帯域幅により、アプリケーションがネットワーク上でスムーズに実行できるようになります。幸いなことに、今日のネットワークは一般にギガビット帯域幅または光ファイバー ネットワークであり、帯域幅の問題がアプリケーションのパフォーマンスに与える影響は徐々に減少しています。

2.2 オペレーティング システム関連のリソース

オペレーティング システムに基づくパフォーマンスの最適化も多面的であり、システムのインストール、システム カーネル パラメータ、ネットワーク パラメータ、ファイル システムなどのいくつかの側面から測定できます。これらについては、以下で簡単に説明します。

1.システムインストールの最適化

システムの最適化は、オペレーティング システムのインストールから開始できます。Linux システムをインストールする場合、ディスクのパーティショニングと SWAP メモリの割り当ては、システムの将来の動作パフォーマンスに直接影響します。たとえば、ディスク割り当てはアプリケーションのニーズに従うことができます:

頻繁な書き込み操作が必要だが、高度なデータ セキュリティは必要ないアプリケーションの場合、ディスクを RAID 0;

にすることができます。

データのセキュリティが高く、読み取りと書き込みに特別な要件がないアプリケーションの場合、ディスクを RAID 1;
• に構成できます。
読み取り操作には高い要件があるが、書き込み操作には特別な要件がなく、データのセキュリティを確保する必要があるアプリケーションの場合は、RAID 5 を選択できます;
高い読み取り/書き込み要件と高いデータ セキュリティ要件を必要とするアプリケーションの場合は、RAID10/01 を選択できます。
• このように、さまざまなアプリケーション要件に応じてさまざまな RAID レベルが設定され、システムはディスクの下部で最適化されます。
メモリ価格の低下とメモリ容量の増加により、仮想メモリ SWAP の設定では、いわゆる仮想メモリを物理メモリの 2 倍にする必要はなくなりましたが、SWAP の設定は無視できません。経験：＃＃＃
• メモリが小さい場合 (物理メモリが 4GB 未満)、通常、SWAP スワップ パーティション サイズをメモリの 2 倍に設定します。
• 物理メモリが 8GB を超え 16GB 未満の場合は、SWAP サイズを物理メモリと同じか、それよりわずかに小さく設定できます。
• メモリサイズが 16GB を超える場合は、原則として SWAP を 0 に設定できますが、ある程度のサイズの SWAP を設定しても一定の効果があるため、これはお勧めできません。

2.カーネルパラメータの最適化

システムのインストールが完了したら、最適化作業は終わりではありません。次に、システムのカーネル パラメーターを最適化できます。ただし、カーネル パラメーターの最適化は、システムに展開されるアプリケーションと併せて考慮する必要があります。

たとえば、システムが Oracle データベース アプリケーションをデプロイする場合、システム共有メモリ セグメント (kernel.shmmax、kernel.shmmni、kernel.shmall)、システム セマフォ (kernel.sem)、およびファイル ハンドルを構成する必要があります。 (fs.file-max) およびその他のパラメータ。Web アプリケーションをデプロイする場合は、net.ipv4.ip_local_port_range、net.ipv4.tcp_tw_reuse、net を変更するなど、Web アプリケーションの特性に応じてネットワーク パラメータを最適化する必要があります。 .core.somaxconn など。ネットワーク カーネル パラメータ。

＃＃＃＃３．ファイルシステムの最適化
ファイル システムの最適化も、システム リソースの最適化の焦点です。Linux のオプションのファイル システムには、ext2、ext3、ReiserFS、ext4、および xfs が含まれます。さまざまなアプリケーションに応じて、さまざまなファイル システムを選択してください。
Linux の標準ファイル システムは、VFS から始まり、ext、ext2 となります。ext2 が Linux の標準ファイル システムであると言えます。ext3 は、ext2 をベースにログを追加して形成されます。VFS から ext4 までは、設計思想はほとんど変わっておらず、すべてスーパー ブロックと i ノードに基づいた初期の UNIX ファミリの設計概念に基づいています。
XFS ファイル システムは、高度なログ ファイル システムです。XFS は、ディスク リクエストの分散、データの検索、キャッシュの一貫性の維持により、ファイル システム データへの低遅延、高帯域幅のアクセスを提供します。したがって、XFS は非常にスケーラブルです。堅牢で、優れたロギング機能、強力なスケーラビリティ、および高速書き込みパフォーマンスを備えています。
現在、サーバーサイドのファイルシステムはext4やxfsが主流ですが、ファイルシステムの特性やビジネスのニーズに応じて適切なファイルシステムを選択する必要があります。

2.3、アプリケーション ソフトウェア リソース

アプリケーションの最適化は、実際には最適化プロジェクト全体の核心であり、アプリケーションにバグがある場合、他のすべての側面が最適な状態に達したとしても、アプリケーション システム全体のパフォーマンスは依然として低いままになります。したがって、アプリケーションの最適化はパフォーマンスです。最適化プロセスの最優先事項は、プログラム アーキテクチャの設計者とプログラム開発者に対してより高い要件を提示します。

3. システムパフォーマンスの分析に関わる担当者

3.1、Linux の運用および保守担当者

パフォーマンスの最適化のプロセスにおいて、Linux の運用および保守担当者は非常に重要なタスクを担っています。
まず、Linuxの運用保守担当者は、システムの負荷、メモリの状態、プロセスの状態、CPUの負荷など、現在のOSの稼働状況を把握し、把握し、検知・判断する根拠となる情報を把握しておく必要があります。システムパフォーマンス;
次に、Linux の運用および保守担当者は、ディスク I/O、CPU モデル、メモリ サイズ、ネットワーク カードの帯域幅、その他のパラメータ情報などのシステムのハードウェア情報を把握し、それに基づいてシステム リソースの使用状況を包括的に評価する必要があります。この情報; ＃＃＃＃＃＃
• 第三に、Linux の運用保守担当者は、アプリケーションによるシステム リソースの使用状況、つまりプログラムのバグやメモリ オーバーフローなどの問題の有無など、アプリケーションの動作効率を理解する必要があります。システムを分析することで リソースを監視することで、アプリケーションに異常があるかどうかを発見することができます アプリケーションに問題がある場合は、直ちにプログラム開発者に問題を報告し、プログラムを改善またはアップグレードする必要があります。
• パフォーマンスの最適化自体は複雑で面倒なプロセスです。Linux の運用および保守担当者は、システムのハードウェア情報、ネットワーク情報、オペレーティング システムの構成情報、アプリケーション情報を理解することによってのみ、サーバー パフォーマンスの目標を絞った最適化を実行できます。 Linux の運用および保守担当者には、十分な理論的知識、豊富な実務経験、および問題を注意深く分析する精神が求められます。

3.2. システム アーキテクチャ設計者

システム パフォーマンスの最適化に関与する 2 番目のタイプの担当者は、アプリケーション アーキテクトです。 Linux の運用保守担当者が総合的な判断を行った結果、パフォーマンスがアプリケーションの実行効率に影響を受けていると判断した場合、プログラム アーキテクチャの設計者がタイムリーに介入して、プログラムの実行状況を深く把握する必要があります。

• まず、システム アーキテクチャの設計者は、プログラムの実行効率を追跡して把握する必要があります。実行効率に問題がある場合は、どこで問題が発生したかを特定する必要があります。 第 2 に、アーキテクチャ設計に実際に問題がある場合は、システム アーキテクチャを直ちに最適化または改善し、より適切なアプリケーション システム アーキテクチャを設計する必要があります。
3.3. ソフトウェア開発者

システム パフォーマンスの最適化の最後のステップには、プログラム開発者が関与します。Linux の運用保守担当者またはアーキテクチャ設計者がプログラムまたは構造上のボトルネックを見つけたら、プログラム開発者は直ちに介入して、対応するプログラムを変更する必要があります。プログラムを変更するときは、プログラムの実行効率をベンチマークとして使用し、プログラムのロジックを改善し、目標を絞った方法でコードを最適化する必要があります。たとえば、Linux の運用保守担当者が、システム リソースを大量に消費する SQL 文をシステム内で発見し、実行された SQL 文を取得したところ、この SQL 文の実行効率が低すぎることが原因でした。開発者が作成したコードの効率を評価するには、この情報を開発者にフィードバックする必要があります。この質問を受け取った開発者は、ターゲットを絞った SQL 最適化を実行してプログラム コードを最適化できます。

上記のプロセスからわかるように、システム パフォーマンスを最適化するために一般的に実行されるプロセスは次のとおりです。

まず、Linuxの運用保守担当者がシステム全体の状況を確認し、主にシステムのハードウェア、ネットワーク機器、OSの構成、アプリケーションのアーキテクチャ、プログラムコードの5つの側面から総合的に判断し、システムに問題があることが判明した場合は、システム全体の状態を確認します。ハードウェア、ネットワーク機器、またはオペレーティング システムの構成、Linux の運用保守担当者は、状況に応じて独自に問題を解決できます。

プログラム構造に問題があることが判明した場合は、プログラム アーキテクチャ設計者に提出する必要があります;

1. プログラムコードの実行に問題があることが判明した場合は、コードの最適化のために開発者に引き渡されます。
2. これでシステム パフォーマンスの最適化プロセスが完了します。
4. 4. チューニングの概要

システム パフォーマンスの最適化は、広範囲にわたる、単調で長期にわたるタスクです。多くの場合、パフォーマンスの問題の根本原因を見つけることが最も難しい部分です。問題の原因が特定されれば、パフォーマンスの問題は簡単に解決されます。 。したがって、問題解決のアイデアが非常に重要になります。 たとえば、Linux システムでの Web サイト システムの場合、Web サイトのアクセス速度が非常に遅く、アクセスできない場合があるとユーザーから報告されました。

この問題について:

最初のステップはネットワークを検出することで、ping コマンドを使用して Web サイトのドメイン名解決が正常であるかどうか、同時にサーバー アドレスへの ping の遅延が大きすぎるかどうかなどを確認できます。 、まずネットワークで考えられる問題を排除します。ネットワークに問題がない場合は、

次に、Linux システムのメモリ使用量を確認する 2 番目のステップに入ります。Web サイトの応答速度が遅いため、通常はメモリに関連しています。free、vmstat などのコマンドを使用して、メモリ リソースが不足しているかどうかを確認します。メモリ リソースが不足している場合は、メモリ リソースに問題はありません

1. 3 番目のステップでは、システム CPU の負荷状況を確認します。sar、vmstat、top などのコマンドの出力を通じて、CPU に過負荷の問題があるかどうかを総合的に判断できます。CPU に問題がない場合は
2. 4 番目の手順に進み、システムのディスク I/O にボトルネックがあるかどうかを確認します。iostat、vmstat、およびその他のコマンドを使用して、ディスクの読み取りおよび書き込みパフォーマンスを確認できます。ディスクの読み取りおよび書き込みに問題がない場合は、 Linux システム自体のパフォーマンスの問題は基本的に解消されますが、最後に、プログラム自体に問題があるかどうかを確認する必要があります。この種の考え方により、レイヤーごとの検出と段階的なトラブルシューティングを通じて、パフォーマンスの問題に「隠れる場所」がなくなり、パフォーマンスの問題が発生するリンクを見つけることが非常に簡単になります。

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