パフォーマンスの検索、パート2：LinuxでのJavaのプロファイリング

火、水、他の人の働きを際限なく見ることができるという意見がありますが、他にも何かがあります！ Sasha goldshtn Goldsteinとパフォーマンスについて延々と話すことができると確信しています。 JPoint 2017の前にすでにSashaにインタビューしていましたが、その会話は特にBPFについてのものであり、Sashaのレポートはそのためのものです。



今回は、パフォーマンスモニタリングとそのソリューションの基本的な問題をより深く掘り下げて調べることにしました。

どこから始めるか

-前回、BPFについて詳細に話し、LinuxでのJavaパフォーマンスの監視の問題について簡単に説明しました。 今回は、特定のツールではなく、問題と解決策を見つけることに集中したいと思います。 最初の質問は、むしろ平凡なものですが、パフォーマンスに問題があることをどのように理解するのですか？ ユーザーが苦情を言っていない場合、私はそれについて考える必要がありますか？



Sasha Goldstein：ユーザーが文句を言ったときだけパフォーマンスについて考え始めると、彼らは長くあなたと一緒にいません。 多くの場合、パフォーマンスエンジニアリングはトラブルシューティングと危機モードです。 電話が鳴り、ライトが点滅し、システムがクラッシュし、キーボードがオンになります-パフォーマンスエンジニアの通常の勤務日。 実際には、彼らは危機の計画、設計、監視、および防止にほとんどの時間を費やしています。



まず、キャパシティプランニングは、予想されるシステム負荷とリソース使用の評価です。 スケーラビリティの設計は、ボトルネックを回避し、負荷を大幅に増加させるのに役立ちます。 計装と監視は、システム内で何が起こっているのかを理解し、盲目的に発掘しないようにするために不可欠です。 自動通知のインストールのおかげで、ユーザーが苦情を申し立てる前であっても、原則として発生する問題について確実に知ることができます。 そしてもちろん、孤立した危機があり、それはストレスの多い状況で解決されなければなりません。



ツールは絶えず変化していますが、プロセス自体は変更されていないことに注意してください。 いくつかの具体例を挙げましょう。膝の上で一枚の紙でできる容量計画。 APMソリューション（New RelicやPlumbrなど）を使用して、エンドツーエンドの計測と監視を行い、ABとJMeterを使用して迅速な負荷テストなどを行うことができます。 詳細については、ライフサイクルとパフォーマンスの方法論に関する優れた情報源であるBrendan Greggの著書Systems Performanceと、パフォーマンスレベルの設定とパフォーマンスの監視に関するトピックのGoogle のサイト信頼性エンジニアリングをご覧ください。



-問題があることを理解したとしましょう：どこから始めればいいですか？ 多くの人（特に非プロのパフォーマンスエンジニア）はすぐにJMHを発見し、すべてを安全でない「ハッカーコンパイラ」に書き換える準備ができているように思えます。 その後、何が起こったかを見てください。 しかし、実際には、これから始めないほうがいいですか？



Sasha Goldstein：これはかなり一般的な方法です。コードを記述してプロファイラーの基本的なテストを実行するとき、コードを変更するかコンパイラーをハッキングすることで簡単に修正できるパフォーマンスの問題があります。 しかし、私の経験に基づいた製品では、これはそれほど頻繁には行われません。 多くの問題は、1つの環境のみに固有のものであり、ワークロードパターンの変更によって引き起こされるか、アプリケーションのコード外のボトルネックに関連付けられます。また、スマートハックによってソースコードレベルでマイクロベンドおよび改善できるのはごく一部です。



以下に、いくつか例を示します。

• 数年前、Datadogは、PostgreSQLでデータベースの挿入と更新が50ミリ秒から800ミリ秒にジャンプしたときに問題に遭遇しました。 彼らはSSDでAWS EBSを使用しました。 それは何を与えましたか？ データベースを調整したり、アプリケーションコードを変更したりする代わりに、EBSスロットリングがすべての原因であることがわかりました。パフォーマンス制限の対象となるIOPSクォータを超える場合です。
• 最近、ガベージコレクションの遅延に関連するサーバーの応答時間の大幅なジャンプの問題を抱えたユーザーがいました。 ガベージコレクションが制御不能になったため、5秒以上かかったリクエストもありました（そして、それらは完全に偶然に見えました）。 システムを注意深く調べた結果、すべてがアプリケーションのメモリ割り当てまたはガベージコレクションの調整で正常であることがわかりました。 ワークロードのサイズの急増により、実際のメモリ使用量が増加し、スワッピングが発生しました。これは、ガベージコレクションの実装に完全に有害です（コレクタがアクティブオブジェクトをマークするためにメモリをポンピングおよびポンピングする必要がある場合、これは終わりです）。
• 数か月前、Sysdigはコンテナ分離の問題に直面していました。コンテナXに隣接しているため、コンテナYが実行するファイルシステム操作は非常に遅く、一方、両方のコンテナのメモリ使用量とプロセッサ負荷は非常に低かったです。 少し調査したところ、カーネルディレクトリキャッシュがコンテナXで過負荷になり、その後ハッシュテーブルの衝突が発生し、その結果、大幅な速度低下が発生することがわかりました。 繰り返しますが、アプリケーションコードまたはコンテナリソースの割り当てを変更しても、この問題は解決しません。

多くの場合、アプリケーションレベルのハッキングなど、制御可能なものに集中する方がはるかに簡単であることを理解しています。 心理的には、これは理解可能であり、システムや環境に関する深い知識を必要とせず、何らかの理由で一部の文化では「よりクール」と見なされます。 しかし、そもそもこれに対処するのは間違っています。



-確かに、最初にアプリケーション/サービスが本番環境でどのように機能するかを確認する必要があります。 これにはどのツールをお勧めしますか？



Sasha Goldstein：製品のモニタリングとプロファイリングは、ツールとテクニックのセットです。



リソース（プロセッサ、メモリ、ディスク、ネットワーク）の使用と負荷特性（＃クエリ、エラー、クエリタイプ、＃データベースクエリ）に焦点を当てた、高レベルのパフォーマンスのメトリックから始めます。 操作およびランタイムごとにこのデータを取得するための標準ツールがあります。 たとえば、Linuxは通常、vmstat、iostat、sar、ifconfig、pidstatなどのツールを使用します。 JVMの場合、JMXベースのツールまたはjstatを使用します。 これらは、おそらく5秒または30秒間隔でデータベースに継続的に収集できるメトリックであり、飛躍を分析し、必要に応じて前の展開操作、リリース、ワールドイベント、またはワークロードの変更を相関させることができます。 多くの人が平均値のみの収集に集中することが重要です。 これらは優れていますが、定義上、測定対象の完全な分布を表すものではありません。 パーセンタイルを収集し、可能であればヒストグラムも収集することをお勧めします。



次のレベルは運用メトリックです。通常は、長期間にわたって継続的に収集または保存することはできません。 これらには、ガベージコレクションログ、ネットワーククエリ、データベースクエリ、クラスロードなどが含まれます。 これらのデータをどこかに保存した後に理解することは、収集するよりもはるかに難しい場合があります。 ただし、これにより、「データベースCPUの負荷が100％に増加したときにどのような種類の要求が機能したか」や「この要求の実行中のドライブのIOPSと応答時間はどうですか」などの質問をすることができます。 特に平均の形式の数字だけでは、この種の研究を行うことはできません。



そして最後に、「ハードコア」レベル：サーバーのSSH（またはツールのリモート起動）は、サービスの通常の運用中に保存できない内部メトリックをさらに収集します。 これらは、一般にプロファイラーと呼ばれるツールです。



Javaプロダクションのプロファイリングには、多くのオーバーヘッドと遅延をもたらすだけでなく、うそをつくことのできる不気味なツールが多数あります。 エコシステムは20年前から存在しているという事実にもかかわらず、JVMアプリケーションのオーバーヘッドが低く、信頼性の高いプロファイリング手法はわずかしかありません。 Andrey Panginの非同期 プロファイラーである Richard WarburtonのHonest Profilerをお勧めします。もちろん、私のお気に入りはperfです。



ところで、多くのツールはプロセッサのプロファイリングに焦点を当てており、どのコード実行が高いCPU使用率を引き起こすかを理解しています。 これは素晴らしいことですが、多くの場合、これは問題ではありません。 メモリ割り当ての原因となるコード実行パスを表示できるツールが必要です（非同期プロファイラーでもこれができるようになりました）、ページエラーの欠落、キャッシュミス、ディスクアクセス、ネットワーク要求、データベースクエリ、その他のイベント。 この分野に私を惹きつけたのは、まさに作業環境を研究するための適切なパフォーマンスツールを見つけることの問題でした。

LinuxのJavaプロファイリング

-Java / Linuxスタックの下では、測定の信頼性に多くの問題があると聞きました。 きっとあなたは何とかこれと戦うことができます。 これをどうやってやるの？



Sasha Goldstein：はい、これは悲しいです。 現在の状況は次のようになります。欠陥を見つけてアプリケーション/サービスの速度を理解するためにテストする必要がある膨大な数の異なる部品を備えた高速コンベヤーラインがあります。 すべての部分を完全にチェックすることはできないため、主な戦略は1秒間に1つの部分をチェックし、すべてが正常かどうかを確認することです。この「テープ」の上にある「小さなウィンドウ」でこれを行う必要があります。 いいですね。 しかし、調べてみると、コンベアベルトで現在何が起こっているかはわかりません。 コンベヤーが魔法の「セーフ」モードに入るまで待機し、その後はすべて見ることができます。 また、コンベアは近くにある間は「セーフ」モードに入ることができないため、多くの部品が表示されることはありません。 また、ウィンドウ内の欠陥を見つけるプロセスには5秒もかかるため、毎秒これを行うことは不可能です。



この状態を中心に、JVMの世界には多くのプロファイラーが存在します。 YourKit、jstack、JProfiler、VisualVM-これらはすべて、CPUプロファイリングに対して同じアプローチを採用しています。スレッドサンプリングを安全な状態で使用します。 これは、文書化されたAPIを使用してすべてのJVMスレッドを一時停止し、スタックトレースを取得し、最もホットなメソッドとスタックでレポートするために収集することを意味します。



このようなプロセスの中断の問題は次のとおりです。スレッドはすぐには停止せず、ランタイムは安全な状態に達するまで待機します。 その結果、アプリケーションの偏った画像を取得し、異なるプロファイラーがまだ互いに同意しない場合があります！



各プロファイラーが同じワークロードで最もホットなメソッドについて独自の観点を持っている場合、それがどれほど悪いかを示す研究があります（Mitkovichら、「Javaプロファイラーの精度の評価」）。 さらに、複雑なSpring呼び出しスタックに1000個のスレッドがある場合、スタックトレースの収集に失敗することがよくあります。 おそらく1秒あたり10回以下です。 その結果、スタックデータは実際のワークロードとはさらに異なります。



このような問題を解決するのは簡単ではありませんが、投資する価値があります。製品の一部のワークロードは、上記のような「従来の」ツールを使用してプロファイルできません。



2つの個別のアプローチと1つのハイブリッドがあります。

• Richard WarburtonのHonest Profilerは、ドキュメント化されていない内部API AsyncGetCallTraceを使用します。これは、単一スレッドのスタックトレースを返し、安全な状態への移行を必要とせず、シグナルハンドラを使用して呼び出されます。 もともとはOracle Developer Studioによって設計されました。 主なアプローチは、信号プロセッサをインストールし、設定された時間（100 Hzなど）の信号に登録することです。 次に、シグナルハンドラ内で現在動作しているスレッドのスタックトレースを取得する必要があります。 明らかに、特にシグナルハンドラのコンテキストでは、効率的なスタックスタックマージに関して困難なタスクがありますが、このアプローチはうまく機能します。 （このアプローチでは、商用ライセンスが必要なJFRを使用します）
• Linux perfは、スタックの豊富なサンプリングを提供できます（CPU命令だけでなく、ディスクアクセスやネットワーク要求などの他のイベントにも）。 問題は、Javaメソッドのアドレスをメソッドの名前に変換することです。これには、perfが読み取りおよび使用できるテキストファイル（perfマップ）を取得するためにJVMTIエージェントが必要です。 JITがフレームポインター抑制を使用する場合、スタックの再構築にも問題があります。 このアプローチはうまくいくかもしれませんが、準備はほとんど必要ありません。 ただし、その結果、JVMスレッドとJavaメソッドだけでなく、カーネルスタックやC ++スタックを含むすべてのスレッドのスタックトレースを取得できます。
• Andrei Panginの非同期プロファイラーは2つのアプローチを組み合わせています。 一連のパフォーマンスパターンをインストールしますが、シグナルハンドラーを使用してAsyncGetStackTraceを呼び出し、Javaスタックを取得します。 2つのスタックを組み合わせると、ストリームで何が起こっているかを完全に把握でき、Javaメソッド名の解決やフレームポインターの抑制の問題を回避できます。

これらのオプションはいずれも、精度、リソース消費、およびレポート頻度の点で、セーフポイントバイアスプロファイラーよりもはるかに優れています。 それらは複雑になる可能性がありますが、オーバーヘッドの少ないプロダクションの正確なプロファイリングは努力する価値があると思います。

コンテナのプロファイリング

-環境といえば、すべてをコンテナに詰め込むのが流行になっていますが、ここに何か機能はありますか？ コンテナ化されたアプリケーションを使用する際に覚えておくべきことは何ですか？



Sasha Goldstein：コンテナには興味深い問題があり、多くのツールが完全に無視し、結果として完全に機能しなくなります。



Linuxコンテナは、コントロールグループと名前空間という2つの主要なテクノロジーを中心に構築されていることを簡単に思い出してみましょう。 監視グループを使用すると、プロセスまたはプロセスのグループ（CPU時間の上限、メモリの制限、IOPSストレージなど）のリソースクォータを増やすことができます。 ネームスペースは、コンテナの分離を可能にします：マウントネームスペースは、各コンテナに独自のマウントポイント（実際には別のファイルシステム）を提供し、PIDネームスペース-独自のプロセス識別子、ネットワークネームスペースは各コンテナに独自のネットワークインターフェイスなどを提供します。 名前空間のため、多くのツールがコンテナ化されたJVMアプリケーションと適切に通信することは困難です（ただし、これらの問題の一部はJVMに固有のものではありません）。



特定の問題について議論する前に、JVMのツールのさまざまな種類の可観測性について簡単に説明した方が良いでしょう。 一部について聞いたことがない場合は、知識を更新してください。

• jpsやjinfoなどの基本的なツールは 、既存のJVMプロセスとその構成に関する情報を提供します。
• jstackは、既存のJVMプロセスからスレッドダンプ（スタックトレース）を取得するために使用できます。
• jmap-既存のJVMプロセスのヘッドダンプまたはより単純なクラスヒストグラムを取得します。
• jcmdは 、以前のすべてのツールを置き換え、JVM接続インターフェースを介して既存のJVMプロセスにコマンドを送信するために使用されます。 これは、JVMプロセスとjcmdがデータを交換するために使用するUNIXドメインソケットに基づいています。
• jstat-クラスのロード、JITコンパイル、ガベージコレクション統計などの基本的なJVMパフォーマンス情報を監視するため。 バイナリ形式のこのデータを使用して/ tmp / hsperfdata_ $ UID / $ PIDファイルを生成するJVMに基づいています。
• Serviceability Agentは、JVMプロセス、スレッド、スタックなどのメモリをチェックするためのインターフェースを提供し、ライブプロセスだけでなくメモリダンプとともに使用できます。 プロセスメモリと内部データ構造を読み取ることで機能します。
• JMX （管理対象Bean）を使用して、既存のプロセスからパフォーマンス情報を受信したり、コマンドを送信してその動作を制御したりできます。
• JVMTIエージェントは、クラスのロード、メソッドのコンパイル、スレッドの開始/停止、競合の監視など、さまざまな興味深いJVMイベントに参加できます。

ホストからコンテナをプロファイリングおよび監視する際に発生するいくつかの問題と、それらを解決する方法を次に示します（今後、これについて詳しく説明します）。

• ほとんどのツールでは、オブジェクトと値を検索するためにプロセスバイナリにアクセスする必要があります。 これらはすべてコンテナのマウント名前空間にあり、ホストからはアクセスできません。 一部には、このアクセスは、コンテナーからのバインドマウントによって、またはシンボル解決中にプロファイラーでコンテナーのマウント名前空間を入力することによって提供できます（これは、 以前のインタビューで説明したperfおよびBCCツールが現在行うことです ）。
• perfマップを生成するJVMTIエージェント（perf-map-agentなど）がある場合、コンテナプロセスID（/tmp/perf-1.mapなど）を使用して/ tmpコンテナリポジトリに書き込まれます。 マップファイルはホストからアクセス可能でなければならず、ホストはファイル名に正しいプロセスIDを待つ必要があります。 （繰り返しますが、perfとBCCはこれを自動的に行うことができます）。
• JVM接続インターフェース（jcmd、jinfo、jstack、およびその他のツールが依存する）には、正しいPIDおよびマウント名前空間接続ファイル、およびJVMとの通信に使用されるドメインのUNIXソケットが必要です。 この情報は、jattachユーティリティを使用してアタッチファイルを作成し、コンテナのネームスペースを入力するか、ホスト上の対応するディレクトリをバインドマウントしてスクロールできます。
• jstatが使用するJVMパフォーマンスデータファイル（/ tmp / hsperfdata_ $ UID / $ PID）を使用するには、コンテナー名前空間をマウントするためのアクセスが必要です。 これは、ホスト上の/ tmpコンテナをバインドマウントすることで簡単に対処できます。
• JMXベースのツールを使用する最も簡単な方法は、おそらくリモートの場合と同様にJVMにアクセスすることです。リモート診断の場合と同様に、RMIエンドポイントを構成します。
• Serviceability Agentツールには、JVMプロセスとホスト間で正確なバージョンの一致が必要です。 特に異なるディストリビューションを使用し、異なるバージョンのJVMがホストにインストールされている場合は、ホストで実行しないでください。

ここであなたは思うかもしれません：パフォーマンスツールをコンテナに入れて、これらのすべての分離問題が私のために発生しないようにしたらどうでしょうか？ 考え方は悪くありませんが、多くのツールはseccompのためにこの構成では動作しません。 たとえば、Dockerはperf_event_openシステムコールを拒否します。これは、perfおよびasync-profilerを使用したプロファイリングに必要です。 また、JVMプロセス内のメモリ量を読み取るために多数のツールで使用されるptraceシステムコールも拒否します。 これらのシステムコールを受け入れるようにseccompポリシーを変更すると、ホストが危険にさらされます。 また、コンテナにプロファイリングツールを配置することにより、その攻撃対象領域を増やします。

---

会話を続け、プロファイリングに対する鉄の影響について話し合いたいと思いました...











Sashaはまもなくサンクトペテルブルクに来て、実稼働環境でのJVMアプリケーションのプロファイリングに関するトレーニングを実施し、 Joker 2017カンファレンスでBPFについてプレゼンテーションを行います。したがって、トピックの詳細を知りたい場合は、Sashaに直接会う機会があります。