Java パフォーマンス チューニング プロジェクトに関するいくつかの提案

2016 年 8 月、Geeknet、InfoQ、Tingyun が共催した APMCon 2016 China Application Performance Management Conference で、Java パフォーマンス チューニングの専門家である Monica Beckwith 氏が「Java パフォーマンス チューニングの必読コード」(原題: Java Performance Engineer's Survival Guide) を実施しました。 ）のスピーチ。講演の中で、Monica 氏は Java チューニングのベスト プラクティスに関する個人的な提案を行いました。つまり、チューニングが必要なパフォーマンス要件の設定方法、分析が必要な指標、目標設定後にチューニングを具体的に実行する方法などです。

Monica Beckwith は、エンタープライズ アプリケーションにおける Java 仮想マシンとガベージ コレクターの最適化に焦点を当てており、ガベージ コレクターと Java メモリ モデルに関する多くの記事を公開しています。彼女は以前 Oracle で働いて G1 ガベージ コレクター パフォーマンス チームを率いており、現在は独立したコンサルタントです。 Monica 氏の講演後、InfoQ は彼女に独占インタビューを実施しました。

パフォーマンスチューニング前の準備作業

Monica は、パフォーマンス最適化プロジェクトは、パフォーマンス要件の分析と計画、およびパフォーマンス結果の分析の 2 つの部分で構成されていると考えています。この 2 つは閉ループを形成し、パフォーマンスを継続的に向上させることができます。

1. パフォーマンス要件の分析と計画

パフォーマンス要件を決定するとき、エンジニアはまず次の 3 つの質問を自問する必要があります:

ユーザーを満足させるものは何ですか?

ユーザーをイライラさせるものは何ですか?

現在の問題 それは支払う必要がありますか?

次に、ユーザーの観点から QoS について考える必要があります。QoS 基準を測定可能な指標、つまり SLA サービス レベル アグリーメントに定量化し、SLA パフォーマンス指標レベル (スループット、応答時間) を定義し、整理し、優先順位を付けます。 、容量、リクエストのフットプリント、CPU 使用率など）。

1. スループット/レート:

目標 - 設定されたスループットよりも低い可能性がありますか?

可能な限り低くできるか?トランザクション数/秒、メッセージ数/秒、またはその両方) どこで測定するか (クライアント、サーバー、またはブラウザー)

目標 - 設定された応答時間を超えることができるか?状態はどれくらい長く続くことができますか?

テスト - 応答時間の 99% を取得して平均を計算します (一定期間 (5 ～ 9 秒))。最悪の場合、またはすべて) どこを測定するか? (クライアント、サーバー、またはループ全体)

3. 許容容量はどれくらいですか? システムが過負荷になった場合 (負荷分散の問題)、どのように容量を測定しますか? ? 1 つのシステムとすべて システムが耐えられる最大容量はどれくらいですか? どのような指標を監視する必要がありますか?

パフォーマンス結果の分析については、Java のパフォーマンス分析のみになります。ここで議論しました。どの要因がエンド ユーザー エクスペリエンスに影響を及ぼし、期待される QoS を達成できないかを分析し、パフォーマンス指標を追跡および監視します。次の図は、階層化された状況図です:

アプリケーション層のエコシステム: アプリケーション サービス、アプリケーション サーバー、データベース、エコシステム内のその他のサービス

JRE 層: クラスの読み込み、JIT コンパイル、ガベージ コレクション、スレッド 状況

システム層: システム/カーネルステータス、ロックステータス、スレッドステータス

ハードウェア層: メモリ帯域幅/メモリスループット/メモリ使用量、CPU/カーネル使用量、CPUキャッシュ効率/使用量/レベル、プロセッサ構造、IOステータス

パフォーマンスの実行チューニング

2 つの実装モード

Monica は、トップダウンとボトムアップの 2 つの実装方法を提案しています。どちらを使用するかは、達成したい内容によって異なります。

アプリケーション レベルから改善を行いたい場合、およびコードを変更できるアプリケーション エンジニアの場合は、トップダウン アプローチを使用できます。

プラットフォーム レベルから改善したい場合は、ボトムアップ アプローチを使用できます。まず、プラットフォームのどのモジュールを改善する必要があるかを特定する必要があります。次に、関連するアプリケーションをリストしてワークロードを評価し、適切なツールを見つける必要があります。

4つのステップ

どの方向にせよ、最初のステップはモニタリング、2番目のステップは誘導、3番目のステップは分析、4番目のステップは最適化と適用です。

一般的に、次の指標が懸念されます。

CPU: CPU ステータス、カーネル ステータス、キャッシュ ヒットとミスの数、分岐予測、パイプライン、条件付き転送、ロードストア動作モードなど

メモリ: メモリ使用量、メモリ、帯域幅、読み取りおよび書き込みステータス、読み取り操作 最大帯域幅、書き込み操作の最大帯域幅、最大容量は、構造に関連します。

JVM/GC: 変更に関連する情報を収集し、一般または同時 GC のさまざまな段階、同時作業キューと作業ステータス、内部キューまたはキャッシュなどに関する情報を収集します。

1. モニタリング

最初のステップは、モニタリングプロセスから開始することです。

監視方法は、アクティブ(アラーム設定)、パッシブ(ネットワークスプリッター)、オフライン(ログキャプチャ)の3種類に分けられます。

選択できるツールは 3 種類あります:

サードパーティ - VisualVM、Java Flight Recorder

JVMにはコマンドが付属しています - PrintCompilation、PrintGCDetails (+PrintGCDateStamps)、jmap-clstats、jcmd GC.class-stats

オペレーティングシステムには付属しています - mpstat、Linux上のsysstat - iostat、pidstat 、prstat、vmstat、dash、CPU-Z、cacti など。Windows では、パフォーマンス モニター、タスク マネージャー、リソース モニター、CPU-Z、cacti などがあります。

2. 次のステップ。は概要と分析のリンクです。

この時点で、必要な情報はすべて揃っています。改善が必要な領域を特定し、改善が必要な潜在的な問題を分析する必要があります。このリンクで使用できるオープンソース ツールには次の 2 種類があります:

サードパーティのパフォーマンス分析ツール - Oracle Solaris Studio Performance Analyzer、perftools、PAPI、Code XL、Dtrace、Oprofile、gprof、LTT

Java プログラム レベル- Visual VM、Netbeans Profiler、JConsole

3、チューニング

最後のステップはチューニングです。 JVM/GC チューニングの焦点は、適切なヒープと適切なガベージ コレクション アルゴリズムを選択することです。まず、オブジェクトの年齢を正しく分割し、各仮想マシンのすべての GC ワーカー スレッド (GC のストップ ザ ワールド現象) と、同じ VM 内の複数の GC スレッドのみを実行します。プレーン オブジェクト ポインターの圧縮が機能する場合、ヒープが大きい場合は、AlwaysPretouch を有効にし、UseLargePages を最適なサイズに設定する必要がある場合があります。さらに、SLA 目標を達成するためにコード レベルで最適化し、適切なランプアップとランプダウン、オブジェクトの年齢区分と保持ポリシー (LDS ファイルの構成を理解する) を設定し、正しい測定を保証します。

Monica に相談してください

InfoQ: パフォーマンス分析中にすべてのログを収集する必要がありますか?

Monica: 何かを調整する必要があることがわかっている場合、通常、ユーザーは運用環境からログを送信します。私たちはその環境をベースに複製します。これを基にして、この複製された環境でテストと検査を行います。運用環境は安定している必要があるため、実際の環境でテストすることはお勧めしません。すべてのログが必要になるのはどのような状況ですか? メモリ リークなど、特定の問題が存在することが確実な場合は、現時点でできる限りすべてのログを収集する必要があります。

InfoQ: いくつかの GC メソッドを分析して簡単な評価を行ってもらえますか?

Monica: ガベージ コレクションは Java アプリケーションのチューニングの中核です。 GC はガベージ情報を収集するだけでなく、ヒープ割り当て情報も管理します。すべての割り当ては同様です。一般に、オブジェクトを世代に分割するためのスペースが小さい場合、ホットスポット JVM では古い世代のオブジェクトで最適化することをお勧めします。若い世代が大多数を占めて死んでしまうからです。古い世代のコレクション アルゴリズムに共通するデフォルトは、ガベージ マーク圧縮アルゴリズムです。

CMS ガベージ コレクターは古い世代のリサイクルをターゲットにしており、ルート オブジェクトから始めて生き残ったオブジェクトにマークを付けます。スペース内に生きているオブジェクトがなくなると、占有されていたリソースが解放され、空きリストに更新されます。CMS が行うことは、空きリストに属する必要がある古い世代のすべてを分割することです。

もう一つのデザインはG1です。リソースをリージョンに分割します。一部のリージョンは一緒に若い世代を構成し、一部のリージョンは古い世代を構成します。つまり、同じ世代のすべてのリージョンが隣接している必要はありません。各地域は最初は任意であり、若い世代または古い世代として宣言する必要があります。収集期間中、必ずしも古い世代が全員参加するとは限りません。 G1はゴミの多いエリアの収集に気を配っています。さらに、G1は若い世代のインターバルサイズの調整にも努める予定だ。

InfoQ: Java で今一番変更したいことは何ですか?

Monica: Java の非ヒープ メモリ管理は JDK 9 または JDK 10 で改善される可能性があります。メモリ リークの検出も難しいと思います。改善する必要がある場所がたくさんあります。

InfoQ: より良いパフォーマンスを達成するために、Java ソフトウェア開発エンジニアは何に注意する必要があると思いますか?

Monica: プログラミングするときは、Java GC がどのように機能するかを考える必要があります。リソースを占有するのは期限切れのオブジェクトではなく、生きたオブジェクトを維持する必要があります。プログラミングするときは、オブジェクトの作成、保持戦略、ガベージ コレクターの動作方法を理解する必要があります。この3つのポイントを考慮して、全体がうまく調整されていれば、無理にすべてを正しく行う必要はありません。