1. システムのボトルネックとなる要因は何ですか?
CPU: 計算が多い場合、長時間継続的に CPU リソースを占有するため、他のリソースが CPU を競合できず、応答が遅くなり、頻繁な FullGC や頻繁なコンテキストなどのシステム パフォーマンスの問題が発生します。マルチスレッドが原因です。切り替えにより CPU がビジー状態になります。一般に、CPU 使用率は 75% 未満であることがより適切です。
メモリ: Java メモリは通常、jvm メモリを通じて割り当てられ、jvm 内のヒープ メモリは主に Java によって作成されたオブジェクトを格納するために使用されます。メモリの読み書き速度は非常に速いですが、メモリ空間には限りがあるため、メモリ空間がいっぱいになってオブジェクトを再利用できなくなると、メモリ オーバーフローやメモリ リークが発生します。
ディスク I/O: ディスクの記憶領域はメモリよりもはるかに大きいですが、ディスクの読み取りおよび書き込み速度はメモリよりも遅いため、SSD ソリッド ステート ドライブが導入されましたが、それでもまだ、SSD ソリッド ステート ドライブの速度には匹敵しません。メモリ。
ネットワーク: 帯域幅のサイズはデータの送信に大きな影響を及ぼします。同時実行の量が増加すると、ネットワークがボトルネックになりやすくなります。
例外: Java プログラムが例外をスローした場合、それをキャッチする必要があります。このプロセスはパフォーマンスを消費します。高い同時実行性で例外処理が継続されると、システムのパフォーマンスに影響します。
データベース: データベース操作には通常、ディスク I/O の読み取りおよび書き込みが含まれます。データベースの読み取りおよび書き込み操作が大量に行われると、ディスク I/O パフォーマンスのボトルネックが発生し、データベース操作の遅延につながります。
並行してプログラミングする場合、同じリソースをマルチスレッドで操作することがよくありますが、このときデータの原子性を確保するためにロックを使用する必要がありますが、ロックを使用するとコンテキストの切り替えが発生し、パフォーマンスのオーバーヘッドが発生します。 JDK1.6以降では、バイアスロック、スピンロック、軽量ロック、ロック粗化、ロック削除が追加されました。
2. システムのパフォーマンスを測定するためにどのような指標が使用されますか?
1.RT応答時間
データベースの応答時間、つまりデータベース操作の時間
サーバーの応答時間には、Nginx によって分散されたリクエストに消費された時間とサーバー プログラムの実行に消費された時間が含まれます。
ネットワーク応答時間、ネットワーク送信、およびネットワーク ハードウェアが送信された要求を解析するのにかかる時間。
クライアントの応答時間は、一般的なWebクライアントやアプリクライアントの場合は無視できる時間ですが、クライアントの論理処理量が多い場合には時間が長くなる可能性があります。
2.TPSスループット
ディスク スループット: IOPS (Input/Output Per Second) 1 秒あたりの入出力。これは、システムが単位時間あたりに処理できる I/O リクエストの数です。I/O リクエストは通常、読み取りまたは書き込みデータ操作リクエストです。読み取りおよび書き込みのパフォーマンス。小規模なファイル ストレージやメール サーバーなど、ランダムな読み取りおよび書き込みが頻繁に行われるアプリケーションに適しています。データスループットは単位時間当たりに送信できるデータ量であり、ビデオ編集など、連続した大量の読み書きや大量の連続データを必要とするアプリケーションで使用されます。
ネットワーク スループット: ネットワーク送信中にフレーム損失なしでデバイスが受け入れることができる最大データ レートを指します。ネットワーク スループットは帯域幅だけでなく、CPU 処理能力、ネットワーク カード、ファイアウォール、および I/O とも密接に関係しており、スループットはネットワーク カードの処理能力、内部プログラム アルゴリズム、および帯域幅によって決まります。
3. リソースの使用量
CPU 使用率は、物理 CPU の数や 1 つの CPU のコア数などの CPU の基本情報を把握し、vmstat、mpstat、top のコマンドで確認できます。
メモリ使用量、free -m、vmstat、top
ディスク I/O、iostat、iotop
ネットワーク I/O、netstat、ifconfig、tcpstat
3. 性能試験を行う際の注意点
パフォーマンス テストを行うと、システムの動作がますます速くなり、その後のアクセス速度は最初のアクセス速度の数倍になります。これは、Java 言語のコンパイル順序が、最初に .java ファイルが .class ファイルにコンパイルされるためです。 、実行する前に、.class バイトコードをインタープリターを通じてローカル マシン コードに変換します。
メモリと実行効率を節約するために、コードが最初に実行されるとき、インタプリタは最初にこのコードを解釈して実行します。コードの実行回数が増えると、仮想マシンは特定のメソッドまたはコードが特に頻繁に実行されていることがわかり、それがホット スポット コードとして識別されます。
ホット コードの実行効率を向上させるために、仮想マシンは実行時にジャストインタイム コンパイラ (JIT) を通じてこれらのコードをローカル プラットフォーム関連のマシン コードにコンパイルし、メモリに保存します。これにより、初めてシステムの実行が遅くなりますが、その後のアクセス時間は数倍速くなります。
パフォーマンステストを行う場合、各テストで処理されるデータセットは同じでも、マシン上の他のプロセスの影響、ネットワークの変動、各テストの影響など、テストには多くの不安定な要素が伴うため、結果は異なります。 JVM ガベージ コレクションの段階は異なります。複数のテストによるテスト結果を平均化することができ、その平均値が妥当な範囲内にあり、変動が大きくない限り、パフォーマンス テストは合格となります。
4. パフォーマンスの問題を特定する場合は、ボトムアップ戦略分析とトラブルシューティングを使用できます。
ストレス テストを実行した後、RT、TPS、TP99、CPU、メモリ、ストレスを受けたサーバーの I/O、JVM の GC 周波数を含むパフォーマンス テストレポートを出力します。これらの指標を通じてパフォーマンスのボトルネックを発見し、ボトムアップで分析できます。
1. まず、OS レベルでシステムの CPU、メモリ、I/O、ネットワーク使用率が異常かどうかを確認し、コマンドを使用して異常なログを検出し、最後にログ分析によってボトルネックの原因を特定します。
2. JavaアプリケーションのJVMレベルからJVMのガベージコレクション頻度やメモリ割り当てを確認して異常がないか確認したり、ガベージコレクションログを分析してボトルネックの原因を究明することもできます。
3. システム レベルおよび JVM レベルで例外がない場合は、Java プログラミングの問題、データベースの読み取りおよび書き込みのボトルネックなど、アプリケーション サービス ビジネス層からのパフォーマンスのボトルネックがあるかどうかを確認できます。
5. パフォーマンスの問題を最適化する場合、トップダウン戦略を使用して最適化できます。
全体的なチューニング シーケンスは、ビジネス チューニングからプログラミング チューニング、そして最後にシステム チューニングに至ることができます。
1. アプリケーション層のチューニング
1 つ目はコードの最適化です。コードの問題は、システム リソースの消費によってしばしば露呈します。たとえば、コードがメモリ オーバーフローを引き起こして JVM のメモリ不足を引き起こしたり、頻繁に FullGC が発生して CPU の使用率が高くなったりするなどです。 。
2 つ目は設計の最適化で、主にビジネス層とミドルウェア層のコードを最適化します。たとえば、プロキシ モードを使用して、頻繁に呼び出されるオブジェクト作成のシナリオに配置して、作成したオブジェクトを共有し、作成の消費を削減できます。オブジェクト。
3 番目のステップは、アルゴリズムを最適化し、時間の複雑さを軽減するために適切なアルゴリズムを選択することです。
2. ミドルウェアのチューニング: MySQL のチューニング
1) テーブル構造とインデックスの最適化
主にデータベース設計、テーブル構造設計、インデックス設定ディメンションの最適化を行いますテーブル構造設計の際には、データベースの水平方向および垂直方向の拡張性を考慮し、将来のデータ量、読み取りおよび書き込み量の増加を事前に計画し、サブスクリプションを計画します。 -databases. サブテーブルプラン。フィールドに適切なデータ型を選択し、より小さいデータ構造を優先します。
2) SQL文の最適化
主に SQL ステートメントを最適化するために、 Explain を使用して実行計画を表示し、インデックスが使用されているかどうか、またどのインデックスが使用されているかを確認します。Profile コマンドを使用して、ステートメント実行中の各ステップで費やされた時間を分析することもできます。
3) MySQLパラメータの最適化
主に、接続数の管理や、インデックス キャッシュ、クエリ キャッシュ、ソート キャッシュなどのさまざまなキャッシュ サイズの最適化など、MySQL サービスの構成を最適化します。
4) ハードウェアおよびシステム構成
オペレーティング システム パラメータの調整、スワップの無効化、メモリの増設、ソリッド ステート ドライブのアップグレードなど、ハードウェア デバイスとオペレーティング システムの設定を最適化します。
3. システムチューニング
1 つ目はオペレーティング システムのチューニングであり、Linux を動作させるためのカーネル パラメーターの設定をチューニングして、高いパフォーマンスを実現することができます。
次に、JVM チューニング、適切な JVM メモリ スペースとガベージ コレクション アルゴリズムを設定してパフォーマンスを向上させます。たとえば、ビジネス ロジックで大きなオブジェクトが作成される場合、大きなオブジェクトを古い世代に直接配置するように設定できます。これにより、YongGC を削減できます。若い世代に頻繁に発生し、CPU 使用時間が減少します。
4. 戦略のチューニング
1 つ目は、時間をスペースと交換することです。システムには、クエリ速度の要件が高くなくても、ストレージ スペースの要件が高い場合があります。このとき、時間をスペースと交換することを考慮できます。
第 2 に、スペースは時間と交換され、ストレージ スペースはアクセス速度を向上させるために使用されます。典型的な例は、MySQL のサブデータベースとテーブル戦略です。MySQL フォーム データが数千万を超えて保存されると、読み取りおよび書き込みのパフォーマンスが低下します。このとき、クエリ時のパフォーマンスを向上させるという目的を達成するために、データを分割することができます。各テーブルのデータは小さくなります。
5. ダイベストメント戦略
システムのチューニング後もパフォーマンスの問題は残ります。このときは、フローを制限し、システム入口の最大アクセス制限を設定すると同時に、カバーアップ戦略を立てる必要があります。 、失敗したリクエストを返すサーキットブレーカー措置を講じます。2つ目は横展開で、訪問数が一定の閾値を超えた場合にシステムが自動でサービスを横展開することができます。
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。