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

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

ShangシリコンバレーのSongHongkangが説明したJVM：bilibili link

1大廠面接の質問

• Alipay

  • Alipayの3つの側面：JVMパフォーマンスチューニングで何が行われたか？

• キビ

  • JVMメモリの最適化を行いましたか？
  • SQL、JVM、アーキテクチャ、データベースの4つの側面から最適化のアイデアについて話します

• Ant Financial

  • JVMコンパイルの最適化
  • JVMパフォーマンスチューニングで行われたこと
  • どのJVM診断ツールが使用されていますか？
  • 2つの側面：JVMの調整方法、適切なヒープメモリとスタックスペースの設定量
  • 3つの側面：どのJVM関連の分析ツールが使用されていますか？特定のパフォーマンス最適化手順は何ですか？

• バイトビート

  • 3つの側面：JVMを調整する方法とパラメーターを調整する方法？

• 拼多多多発症

  • SQL、JVM、アーキテクチャ、データベースの4つの側面から最適化のアイデアについて話します

• Jingdong

  • どのJVM診断ツールが使用されていますか？
  • 毎秒数十万の同時トランザクションがあるスパイクシステムでGCが頻繁に発生するのはなぜですか？
  • 毎日の平均百万レベルの取引システムのためにJVMを最適化する方法は？
  • オンライン生産システムOOMを監視、特定、解決する方法は？
  • G1ガベージコレクターに基づく並行性の高いシステムのパフォーマンスを最適化するにはどうすればよいですか？

2背景説明

2.1本番環境の問題

• 本番環境でのメモリオーバーフローに対処するにはどうすればよいですか？
• 実稼働環境では、サーバーにどのくらいのメモリを割り当てる必要がありますか？
• ガベージコレクターのパフォーマンスを調整するにはどうすればよいですか？
• 実稼働環境での高いCPU負荷にどのように対処しますか？
• 実稼働環境はアプリケーションにいくつのスレッドを割り当てる必要がありますか？
• ログを記録せずに、リクエストで特定のコード行が実行されたかどうかを判断するにはどうすればよいですか？
• ログがない場合、特定のメソッドの戻り値をリアルタイムで表示するにはどうすればよいですか？

2.2なぜ最適化する必要があるのですか？

• OOMを防ぐ
• OOMを解く
• フルGCの頻度を減らす

2.3さまざまな段階での考慮事項

• オンラインにする前に
• プロジェクト運用フェーズ
• OOMがオンラインで表示される

3チューニングの概要

3.1モニタリングの根拠

• 実行ログ
• 例外スタック
• GCログ
• スレッドスナップショット
• ヒープダンプスナップショット

3.2チューニングの一般的な方向

• 合理的なコードを書く
• ハードウェアリソースの完全かつ合理的な使用
• 合理的なJVMチューニング

パフォーマンスを最適化する4つのステップ

• 最初のステップ（問題の発見）：パフォーマンスの監視

  非強制的または侵入的な方法でアプリケーションのパフォーマンスデータを収集または表示するアクティビティ。監視とは、通常、本番環境、品質評価、または開発環境で実装される予防的または予防的な活動を指します。アプリケーションの利害関係者がパフォーマンスの問題を提起しても十分な手がかりを提供しない場合は、最初にパフォーマンスモニタリングを実行し、次にパフォーマンス分析を実行する必要があります。

  • 頻繁なGC
  • CPU負荷が高すぎる
  • おじさん
  • メモリーリーク
  • デッドロック
  • プログラムの応答時間が長くなります

• 2番目のステップ（トラブルシューティング）：パフォーマンス分析

  動作パフォーマンスの問題の応答結果を収集するための煩わしい方法は、アプリケーションのスループットまたは応答性に影響を与えます。パフォーマンス分析はパフォーマンスの質問に対する答えであり、通常、焦点はパフォーマンスの監視よりも焦点が絞られています。パフォーマンス分析は、実稼働環境で実行されることはめったにありません。通常、品質評価、システムテスト、または開発環境で実行されます。これは、パフォーマンス監視の後のステップです。

  • GCログを印刷し、GCviewerまたはgceasyを介してログ情報を分析します
  • コマンドラインツール、jstack、jmap、jinfoなどの柔軟な使用。
  • ヒープファイルをダンプし、メモリ分析ツールを使用してファイルを分析します
  • Ali Arthasまたはjconsole、JVisualVMを使用して、JVMステータスをリアルタイムで表示します
  • jstackビュースタック情報

• 3番目のステップ（問題の解決）：パフォーマンスの調整

  パラメータ、ソースコード、および属性構成を変更して、アプリケーションの応答性またはスループットを向上させるアクティビティ。パフォーマンスチューニングは、パフォーマンスの監視と分析の後のアクティビティです。

  パフォーマンスチューニングの目的：GCの頻度を減らし、より少ないメモリでより高いスループットとより低いレイテンシを実現します

  • ビジネスの背景に応じて、メモリを適切に増やし、ガベージコレクタを選択します
  • コードを最適化し、メモリ使用量を制御します
  • 機械を増やし、節点圧力を分散させます
  • スレッドプール内のスレッド数を合理的に設定する
  • ミドルウェアを使用して、キャッシュ、メッセージキューなどのプログラム効率を向上させます。
  • その他…

5パフォーマンス指標/テスト指標

• 一時停止時間（または応答時間）

  要求を送信してから要求に応答を返すまでに使用される時間は、通常、応答時間に関係します。

  • 一般的な操作の応答時間のリスト

    オペレーティング	反応時間
    サイトを開く	数秒
    データベース内のレコードをクエリします（インデックス付き）	10ミリ秒
    メカニカルハードディスクのアドレス指定を1回	4ミリ秒
    メカニカルハードディスクから1Mデータを順次読み取る	2ミリ秒
    SSDディスクから1Mデータを順次読み取る	0.3ミリ秒
    リモート配布されたRedisからデータを読み取る	0.5ミリ秒
    メモリから1Mデータを読み取る	10マイクロ秒
    Javaプログラムのローカルメソッド呼び出し	数マイクロ秒
    ネットワーク伝送2Kbデータ	1マイクロ秒

    • ガベージコレクションリンクで、一時停止時間：ガベージコレクションが実行されたときにプログラムのワーカースレッドが一時停止される時間。-XX：MaxGCPauseMills

• スループット

  • 単位時間あたりに完了した作業（要求）の量の測定
  • GCの場合：合計実行時間（合計実行時間：プログラム実行時間+メモリ回復時間）に対するユーザーコードの実行時間の比率は、1-1 /（1 + n）です。-XX：GCTimeRatio = n

• 並行性

  同時に、サーバーと実際にやり取りしたリクエストの数。

  1000人が同時にオンラインになっている場合、同時実行の数は5％〜15％、つまり同時同時実行の量は50〜150であると推定されます。

• メモリフットプリント

  Javaヒープ領域が占めるメモリの量

• 相互関係

  例として高速道路の交通状況を取り上げます。

  • スループット：高速道路を毎日通過する料金所の数（料金所が請求する高速料金としても理解できます）
  • 同時数：高速道路上の車両の数
  • 対応する時間：車速

  車が少なく、速度が速く、料金が安い---->並行性が少なく、応答時間が速く、スループットが低い

  車両の数を適切に増やすと、速度が速くなり、料金が高くなります---->同時接続の数が適切で、応答時間が速く、スループットが大きくなります

  車が多すぎる、速度が遅い、料金が低い---->並行性が多すぎる、応答時間が遅い、スループットが低い