Javaパフォーマンスダイアログ

毎年、 JPointの専門家はJavaのパフォーマンスに関する筋金入りのレポートを作成します。 そして、それは決して退屈ではありませんでした-問題は長年にわたって関連したままです。 神話の起源、JVMの役割、生産性の測定方法、顧客のビジネスに必要なもの、Javaパフォーマンスが問題ではなく仕事である専門家と話し合ったレーキの一部を回避する方法について。

Javaパフォーマンスと全能のJVM

Java仮想マシン（JVM）側で何が起こりますか、パフォーマンスにどのように影響しますか？ SAP Volker Simonisの JVMエンジニアと、これについて、およびJavaパフォーマンス全般について少し話しました。 フォルカーは英語で質問に答えました。ここで翻訳を公開します。



-なぜJavaが遅く、パフォーマンスの問題が重要であると言われているのですか？



-Javaが遅いものとして認識されるのは過去のことだと思います。 現在、Java仮想マシンには、非常に高度なJITコンパイラとガベージコレクションアルゴリズムがあり、通常のアプリケーションに非常に優れたパフォーマンスを提供します。 もちろん、JavaがネイティブC / C ++アプリケーションよりも遅い例は常に見つかります。 ただし、Hadoop、Neo4j、H20などのシステムは、大規模で複雑な高負荷のアプリケーションでさえJavaで記述できる例です。 つまり、Javaのパフォーマンスは非常に高く、Javaテクノロジーとして非常に競争力があります。



私の経験では、今日の人々は、Ruby（JRuby）、Clojure、Scalaなど、JVMの「代替」言語のパフォーマンスについて不満を述べています。 JVMは純粋なJavaコードと同様にそれらを最適化できると思います。 それは時間の問題です。



-Javaパフォーマンスを評価および測定する方法



-Javaのパフォーマンスの測定は本当の科学です。 Oracle、Google、Twitter、Odnoklassnikiなどの企業が、経験豊富で資格のある従業員で構成される専任のパフォーマンスチームを持っていることは驚くことではありません。

Javaアプリケーションの使い慣れたパフォーマンスプロファイリングアプローチは、常に失敗する可能性があります。



現在、OpenJDKの一部であるJava Microbenchmark Harness、または簡潔にするために、JMH Aleksey Shipilev（少なくともロシア語の出版物では、これは「」を介して主張しています）は、パフォーマンスの測定および分析の標準として確立されています中小規模のJavaアプリケーション。 JMH実装の複雑さと創意工夫により、Javaアプリケーションのパフォーマンスを正確に測定するためにJMHが何をするのかがわかります。 http://shipilev.net/にある彼のブログは、Javaのパフォーマンスと最適化の問題に関する不可欠な情報源です。



また、JMHは主にJavaコードのパフォーマンスの測定と最適化を担当しますが、GCパフォーマンスの改善には引き続き問題があります。 そして、これは独自の異なるツールと専門知識のセットを必要とする別の話です。



-最も一般的なパフォーマンスの問題はどこにありますか？



-もちろんこれは、Javaアプリケーションのタイプに大きく依存します。 データバインドアプリケーションについて話している場合（つまり、巨大なデータに対して単純なコードを実行する場合）、GCアルゴリズムを正しく選択して構成することがおそらく重要です。 この場合でも、最初にアプリケーションを最大帯域幅向けに最適化するか、アプリケーションのレイテンシをより重視するかを選択する必要があります。



一方、アプリケーションが計算に依存している場合は、JMHやネイティブプロファイラーなどのツールを使用して、仮想マシンがロードされたすべての実行可能ブランチを実際に完全に埋め込み、最適化することを確認できます。

緊密に並列化されたアプリケーションの場合、正しい同期/ブロッキングポリシー（アプリケーションが実行されているハードウェア/プラットフォームによって異なる場合があります）を選択することをお勧めします。 。



しかし、最も重要なルール：仮想マシンは、不完全に記述されたコードを高性能プログラムに変えることはできないため、ほとんどの努力はアルゴリズムの正確さに向けられるべきです。 上で説明したように、JVMレベルでの微調整は常に開発サイクルの最後のステップに過ぎません。



-あなたはJVMのエキスパートです。 JVMはどのくらいの頻度でパフォーマンスの低下を引き起こしますか？ 主な問題とその対処方法は何ですか？



-理想的には、一定回数の反復の後、JavaアプリケーションはコンパイルされたJITコードが少なくとも95％の時間実行される状態に到達する必要があります。 この場合、定期的ですが、かなり短いGCポーズが発生します。 これは、JConsole、JITwatch、Flight Recorderなどのツールを使用して簡単に検証できます。 そうでない場合は、仮想マシンのどの部分が問題を引き起こしているかを見つけ、対応するVMコンポーネントを不明瞭にする（または最適化する）必要があります。



HotSpot JVMの製品バージョンには、約600のいわゆる高度なオプション（これらは-XXで始まるオプション）があり、デバッグビルドには1200を超えるオプションが含まれていることがわかります（完全なリストを取得するには、キーを使用できます） -XX：+ PrintFlagsFinal）。 これらのオプションを使用すると、仮想マシン内で何が起こっているかについての詳細情報を取得できます。 しかし、最も重要なことは、これらのオプションを使用して、仮想マシンのほぼすべてのサブシステムを微調整できることです。 悪いニュースは、これらのオプションが十分に文書化されていないことです。そのため、ソースを調べて、実際に何が起こっているのかを理解する必要があるでしょう。



ガベージコレクションのいくつかの問題は、正しいガベージコレクタ（HotSpotの現在のバージョンには多数あります）と正しいヒープ構成を選択することで解決できます。 生成されたコードのパフォーマンスの問題は、多くの場合、インライン化する間違ったコードを選択することによって引き起こされます。 繰り返しますが、これはある程度影響しますが、残念ながら、これは非常に複雑なトピックであり、他の部分のパフォーマンスに影響を与えずにコードの一部を改善することは困難です。



ロック、スレッドの期待、およびキャッシュのさまざまな効果も、よくある問題の原因です。 しかし、そのソリューションには、仮想マシンの深い知識と、ハードウェアプラットフォームとオペレーティングシステムの内部の知識が必要です。



最後に、最近、仮想環境でのJavaの問題が増加していることに注意してください。 JVMは、環境に最適に適応するために、起動時に多数の「自己構成」を実行します。 ただし、実際のリソースに関する情報（CPUの数や使用可能なメモリの量など）がJVMが受け取ったものと一致しない場合、パフォーマンスが非常に低下する可能性があります。



たとえば、オペレーティングシステムが多数の使用可能な論理CPUを報告した場合、仮想マシンはガベージコレクションとJITのスレッドを多数作成します。 ただし、ホストオペレーティングシステムがこれらのスレッドを非常に少数の物理CPUに分散する場合、Javaアプリケーションのユーザースレッドは、仮想マシンのシステムスレッドに完全に置き換えることができます。 ゲストオペレーティングシステムが一部のJVMに大量のメモリを割り当てるが、このメモリが他のゲストOS間で共有（共有）される場合、同様の問題が発生します。



-メモリ管理アルゴリズムは現在JVMにどのように実装されていますか？開発者がパフォーマンスの問題をより少なくするために何が行われていますか？



-実際、HotSpot仮想マシンはさまざまなメモリ管理システムと戦略を使用しています。 通常のJavaプログラマーにとって最大かつ恐らく最も有名なのは、もちろん、これに取り組んでいるヒープとヒープ収集のガベージコレクションアルゴリズムです。



ただし、JVMは他の多くのメモリプールでも機能します。 ロードされたクラスを格納するメタスペースと、仮想マシンによって生成されたコードを格納するためのキャッシュがあります（最もよく知られているコードの形式は、JITによってコンパイルされたメソッド、およびインタープリターの生成された部分とさまざまなコードスタブです）。

最後に、GCやJITコンパイラなどの仮想マシンのさまざまなサブシステムでは、ジョブを実行するためにしばらくの間かなりのネイティブメモリが必要になる場合があります。 このメモリは通常オンザフライで割り当てられ、さまざまなセグメント、リソースゾーン、またはサブシステムキャッシュでサポートされます。 たとえば、大きなメソッドをコンパイルするJITでは、一時的に1ギガバイトを超えるネイティブメモリが必要になる場合があります。 これらのメモリプールはすべて、アプリケーションに合わせてカスタマイズできます。



-Javaのパフォーマンスに問題があったときの実践から興味深い話を教えてください。 どのように解決されましたか？



「当社のSAP JVMは、PARISCおよびItanium CPU上のHP-UXを含む多くの異なるプラットフォームで実行されます。 Itanium上のHP-UXは、PARISCバイナリファイルのソフトウェアエミュレーションを提供し、PARISCアプリケーションの実行を簡単かつ透過的にします。 確かに、ネイティブアプリケーションよりも1桁遅いです。



HP-UX / Itanium JVMのパフォーマンスが非常に低いというお客様からの苦情が多く寄せられた後、何が起こっているのかを把握し始めました。 クライアントはPARISCバイナリを使用してHP-UX / Itaniumで実行することが判明しました。 各クライアントにエミュレーションの複雑さを説明できなかったため、次のバージョンのJVMにチェックを追加しただけで、プログラムエミュレーションモードでのPARISCのコード実行が禁止されました。

エンタープライズ向けのJavaパフォーマンス

同意します。アプリケーションが実稼働に入り、ブレーキとフリーズに関するクライアントからの不快なコメントが返された不快な瞬間です。 Javaパフォーマンスの問題は、主にエンタープライズソリューションにとって重要です。 そのため、筋金入りの実用的なアドバイスを得るために、NetCracker（テレコムソリューション企業）のパフォーマンスアーキテクトVladimir Sitnikovに専門家を依頼しました 。



「教育環境とプロフェッショナル環境の両方で潜在的なJavaパフォーマンスの問題について聞いたことがあります。 すべてのジョークにはほんの一部のジョークがあります。 一部には、Javaの遅さは神話です。特にプラットフォームのパフォーマンスは時間とともに変化し、10年前に批判されてきたことが今ではまったく異なる方法で機能するためです。 「スローダウン-スローダウンではない」レベルでJavaのパフォーマンスについて話すのは無謀です。



実際には、産業用アプリケーションの主な問題は、問題を解決するために必要なアクションよりも多くのアクションが実行される場合の過剰なコードの存在に関連しています。 どこかで、開発者はあまりにも賢明でしたが、どこかでビジネス要件が非常に混乱しているので、最初はすぐに書くことができません。 鉄の性能で十分な場合もあれば、予想よりも解決が遅い場合もあります。 ここでの主な推奨事項は1つです。不要なコードまたは少なくともその一部を実行しないでください。



パフォーマンスが低下するもう1つの理由は、アルゴリズムにあります。 たとえば、アルゴリズムの基準でレコードを見つけるのではなく、徹底的な検索を使用する場合。 しかし実際には、パフォーマンスを向上させるために独創的な（HashMapよりもスマートな）データ構造が使用されることはほとんどありません。



ライブラリやフレームワークなどのパフォーマンスおよびサードパーティの開発ツールに影響を与える可能性があります。 実際には、問題はすべてのレベルにある可能性があります-そして、それらは起こります。 開発者は通常、テストでそれらを識別し、分析はさまざまなプロファイリング手法（ブラウザーレベル、アプリケーションサーバー、データベース）を使用して実行されます。 サードパーティのコードで問題が発生することがよくあり、それらをキャッチする唯一の方法は、測定を行い、この非常にサードパーティのコードの開発を注意深く監視することです。 私の練習では、毎月が発見です。 1行のコードを置き換えると、データベースへのデータの挿入が10倍速くなります。



一般に、Javaパフォーマンスの測定と操作の主なことは、負荷テストを忘れないことです。 したがって、エンタープライズ開発のためのビジネス要件がどれほど大きくて厳しいのか、それをテストし、パフォーマンスに関連する不快な瞬間に気付くのに役立つ巨大なテスト。 たとえば、企業環境の負荷が均等でないことを考慮する必要があります：朝に全員が入って、システムに入り、ワークロードのピークに達し、その後低下し、午後に負荷が最小になり、昼食後にユーザーが新しい力で負荷を高い値に増やします。 もちろん、最初の分析では、そのようなニュアンスは見落とされる可能性があります。 実際、パフォーマンスの問題を回避するために、大量のロードが予想される場所とコードの記述方法に大きく影響します。



最も一般的な間違いや熊手について私に尋ねています。 それぞれに独自のものがあります。 たとえば、特定のプロセッサまたはメモリモデルを選択してもほとんど変更されません。 もちろん、2006年と2016年のサンプルを比較する場合、モデルは重要です。 多くの質問はスケーラビリティの面にあります。 多くの企業が企業開発の聖杯を求めています。誰もが必要なサーバーの数とアプリケーションを展開するためのパワーを予測するために単一の測定を行いたいと考えています。 ここでの唯一の方法は、稼働中のサーバーでテストし、フォールトトレランスのためにリソースの予約を考慮することです。



一般的に、おそらく、普遍的な最適化ツールがあります-テストの必然性。 ストレステストと結果の分析のスペシャリストがいますが、主な効果は、開発者がコードの速度に責任を持つときに達成されます。 パフォーマンスは、あなたが実際に取って追加できるものではありません。 問題が発生する場所を予測することは困難です。ソースコードのすべての行を疑う十分な時間はありません。 一般的な問題は、テストが誤って、間違った量のデータ、または間違った負荷と構成で実行されたことです。 たとえば、テスト中にライブラリが更新されず、顧客が選択して更新した-問題がないことを考慮してください。



私の記憶には、パフォーマンスの問題を回避しようとしたプロジェクトがありましたが、これらは小規模なデモプロジェクトであるか、アプリケーションの動作が遅いという顧客からの苦情ですぐに戻ってきました。



多くの場合、パフォーマンスの低下やアプリケーション全体の低下は、1つのグローバルエラーだけでなく、2つまたは3つの問題の組み合わせが原因であり、それぞれが一見すると脅威ではありません。 そして最悪のことは、開発者が自分のコードで生じた問題を知らない可能性があることです。 技術サポートエンジニアが問題を解決できる場合、彼らはそれを「報いる」ためにコードの作者を探すことはめったにありません。



苦情といえば。 クライアントがinしている場合、問題を探す場所を見つけるための簡単なアルゴリズムがあります。 顧客の代表者と、その方法を尋ねる必要があります。 すべてがゆっくりと機能し、問題が主観的な感覚であるように思われる場合は、それが機能する時間を指定します。 もちろん、このような要件は、事前に（開発中、または開始する前に）収集することをお勧めします。 要件をコンポーネントに分解します。たとえば、ユーザーが5秒以内にページを開くようにしたい場合、予算をブラウザーに割り当てます（1秒、サーバー側に3.5秒、ネットワークに0.5秒など）。 多くの場合、内訳はシステム自体のコンポーネントにまで及んでおり、ちなみにランタイムはログに記録され、開発者はプロファイラーを開くことで、コードが受け入れ可能なフレームワークに適合するかどうかを確認できます。



だから問題があります。 どこを見て、どこから足が伸びているのか？

• CPU負荷とGCログの内容を確認します。 システムがロードされ、同時に負荷がGCによって引き起こされる場合、メモリが少ない（-Xmxを増やす必要があります）か、「誰かが食べすぎています」。
  
  
  
  
• それ自体では、50〜100％のワークロードが既に、応答時間が最も想像を絶する可能性があることを示唆しています。
  
  
  
  
• 障害はサードパーティのアプリケーションにあることが起こります。 無害なアップデートは、「贈り物として」ブレーキのパックをもたらすことができます。 標準的な例は、RedHat Linuxのストーリーです。透過的な巨大ページメカニズムがパフォーマンスの問題を引き起こします。 これはRed Hat Linuxの「機能」です。その理由は、Javaアプリケーションとデータベースの両方を「突然」遅くし始めるためです。 Red Hat Linux 6+（CentOS 6+）が影響を受けます。 詳細はここをクリックしてください。 THPモードを無効にする必要があります。 ハードウェアとプログラムのそのような調整が手動で実行される場合、人的要因は除外されず、結果として-ブレーキ。
  
  
  
  
• 「以前は機能していましたか」「何が変更されたか」という古典的な質問をします。 クライアント側で何をしたか、システムコンポーネントの更新プログラムをロールしたかどうかを尋ねます。 ロールされた場合-検索ベクトルがより明確になります。 明確でない場合、メモリは空いているので、プロファイラでどのアクティビティがリソースを消費しているかを調べます。 それでは、誰もが独自のコードで独自のストーリーを持っています。
  
  

次に、実際の条件に近い、クライアントに近いパフォーマンスの問題を見てみましょう。 多くの場合、アプリケーションは実稼働環境で非常に予期しない動作をしますが、テストではすべてが完璧でした。 これには説明があります。 状況がクライアントのみによって再現される場合、これはソースデータの問題を示している可能性があります。 たとえば、アプリケーションは1'000'000クライアントで操作を完了する必要があることがわかっています。 私たちは1'000'000のランダムな名前と姓を生成し、テストは成功し、フルネームでクライアントを検索します。 私たちは本番に残します-ユーザーはinします。 問題のある検索をより詳細に調べます-数千のIvanov Ivanov Ivanovichがいることがわかりました。 ストレステストでそれほど多くの繰り返しが考慮されない場合、見つかった行がテストですぐに表示され、操作中に検索が1回おきに動作するのも不思議ではありません。



テスト用の正しいデータセットを生成することは科学です。 意味のある、たとえば100 GBのデータを作成するだけでなく、データ間の相互作用も考慮する必要があります。これは、稼働中のものとできるだけ類似している必要があります。

• 理想的なケースは、クライアントベースダンプの存在です。 直接使用することも、事前に暗号化して使用することもできます。 さらに、暗号化では、オブジェクト間の既存の関係とリンクを考慮し、同時にデータのセキュリティを確保する必要があります。 たとえば、すべての値をMD5に置き換えるだけでは十分ではありません。 MD5でのGoogle検索でも、「元の」値を見つけることができます。 一方では同じデータが同じハッシュにハッシュされるようにHMACを使用する方がより正確ですが、復号化は不可能です。
  
  
  
  
• ダンプがないことも起こります。 この場合、将来のシステムのパラメーターが調査され、これらのパラメーターに基づいてテストデータを生成するスクリプトが作成されます。 この場合、実際には分布が均一な場合はめったにないため、均一な分布は避ける必要があります。
  
  

エンタープライズ向けのJavaパフォーマンスについて他に言えることはありますか？ 顧客の機能以外の要件を収集します。作業シナリオの内訳、特定のアプリケーションモジュールとのユーザーインタラクションの頻度、ユーザー数、予想時間。 後の段階でパフォーマンスの問題を修正するのは非常に費用がかかる可能性があり、コールセンターのオペレーターが待機している間に余分な時間がかかると、深刻な損失につながります。

---

専門家のコメントについてご質問がある場合、またはJavaパフォーマンスの問題についてのご意見をお望みの場合は 、4月22〜23日に開催されるJPoint 2016カンファレンスにコメントしてください 。 私たちは皆そこにいます！