Clever Geek Handbook

JHiccupを使用したシステムレイテンシの監視



JHiccupについて



JHiccupは、エンドアプリケーションに関してオペレーティングシステムのレイテンシを測定する単純なプログラムです。 OSの遅延を測定するために、AzulのCTOであるGil Shadowによって書かれました。









遅延が非常に重要な理由



私たちはネットワークアプリケーションの時代に生きています。 コンピューターで実行されているほとんどのプログラムは定期的にオンラインになります。 ブラウザを起動してgoogle.comを開くと、50〜60のリクエストが発生します。









google.comを開くために56件のリクエストが発生しました







より複雑なサイトについて話すと、リクエストの数は数百になります。 また、これらのリクエストを遅らせると、サイト全体のレンダリングが遅れる場合があります。







サイトの例を調べてみると、クライアントサーバーアプリケーションや一般的なマイクロサービスと簡単に類推できます。 マイクロサービスによる一連の呼び出しの中で、マイクロサービスの1つが通常よりも遅れて応答を返す場合、ロジック全体の速度が低下する可能性があります。 たとえば、データベースからの製品の価格に関する応答が遅いと、オンラインストアでの購入プロセス全体が遅くなる可能性があります。







したがって、プログラムのパフォーマンスと遅延について話すとき、最良の結果と平均の結果だけでなく、最悪の結果も重要です。







OS監視が必要な理由



多くの場合、開発者は、クライアントまたは他のシステムから、アプリケーションが要求を長時間処理したという苦情を受け取ります。 残念ながら、このような問題は、ローカルで再現すること、または実際の環境で通知することすら困難な場合があります。







この場合、多くの開発者はすぐにコードの問題を探し始めます。 これには、たとえば、ログ、メトリック、およびプロファイラーが使用されます。 しかし、適切なパフォーマンス分析は、鉄とスズメバチのレベルから始まり、プログラムで終わる、ボトムアップから開始する必要があります。







ほとんどのスズメバチはリアルタイムオペレーティングシステムではありません。 そのため、一定の期間、操作の実行を保証することはできません。 これは、そのようなOSで実行されているプログラムのパフォーマンスは、プログラムの実行中に大きく変化する可能性があることを意味します。 簡単に言えば、プログラムはある時点でプロセッサー時間さえも受け取らないかもしれません。 そして、プログラムでどのコードが実行されるかは問題ではありません。







プログラムが有用なアクションを実行することなく「スリープ」できる理由はいくつかあります。









なぜjHiccupなのか？



システムのさまざまなコンポーネントの負荷をさまざまな詳細度で確認できるユーティリティとメトリックが多数あります。 問題は、そのようなメトリクスがたくさんあり、プログラマーごとに2つの質問に答える必要があることです。









jHiccupを使用すると、アプリケーションの観点からシステムを見ることができます。 jHiccupは単純な機能を備えた小さなアプリケーションです。無限のストリームがスリープ状態になり、一定期間（たとえば1秒）後にハチに目覚めさせるように要求します。 スズメバチが1秒後にビジーでストリームをウェイクできなかった場合、アプリケーションは、アウェイクの時間をアウェイクの推定時間（スリープ状態になる時間+ 1秒）と比較することでこれを確認します。 プログラムの実行中にシステムの遅延を確認できるグラフを作成できます。









X軸のプログラム実行時間（秒単位）。 Y軸のウェイクアップ遅延（ミリ秒）（OSが実行できるようになるまでプログラムが待機した時間）







クライアントに対するシステムの応答が遅いことに関する苦情の時間を把握し、プログラムを起動する際の遅延のスケジュールを確認することで、遅延の理由があったかどうかを判断できます。







前のグラフでは、プログラムの実行時間に関する遅延を見ました。 さらに、すべての遅延を取得して昇順に並べ替えることが便利です。 これにより、遅延の分布とその可能性がわかります。









y軸のミリ秒単位の遅延とx軸の確率







JHiccupのいくつかの機能 ：









内部jHiccupは、ヒストグラムをデータ構造として使用します。 通常のヒストグラムは、遅延間隔全体（たとえば、1ミリ秒から1秒）をセグメントに分割し、特定の間隔で落ちた遅延の数をカウントします。 これにより、観測値のリスト（1.55ms、2.6msなど）よりもコンパクトな形式で遅延に関するデータを表示できます。







実際、jHicuupはヒストグラムの特別な実装であるHDR-Histogramを使用します。これには次のプロパティがあります。









HDR-Histogramライブラリーは広く普及しています。 さまざまな言語の実装を見つけることができます。 メトリックを収集するためのさまざまなシステムは、そのコンパクトさと正確さにより、内部形式の1つとしてhdr-historgramをサポートし始めました。







なぜそんなに正確なのか？



上記のグラフでは、99.9999％のケースのデータが見られました。 多くの人は、そのような精度が必要かどうか、95％または99％パーセンタイルを超えるデータを考慮する必要があるかどうかについて疑問を持っています。 2つの例を見てみましょう。 両方の例で、異常遅延の確率P（A）をそれぞれ5％および1％とします。 ユーザーが異常なリクエストP（B）を見る可能性はどれくらいかという質問に答える必要があります。









ご覧のとおり、95番目または99番目までのデータのみを考慮するだけでは十分ではありません。







JHiccupの例



jhiccupはhttp://www.azul.com/downloads/jhiccup/またはhttps://github.com/giltene/jHiccupからダウンロードできます。 







./jHiccup -d 4000 /usr/bin/java org.jhiccup.Idle -t 300000 #  4     ,    300 .       5  (    -i). #  hiccup.170617.1120.3461.hlog ./jHiccupLogProcessor -i hiccup.170617.1120.3461.hlog -o hiccup.170617.1120.3461 #  hiccup.170617.1120.3461  hiccup.170617.1120.3461.hgrm


hiccup.170617.1120.3461ファイルは、jHiccupPlotter.xls Excelファイルを使用して表示できます。











hiccup.170617.1120.3461.hgrmを表示するには、オンラインアプリケーションhttps://hdrhistogram.github.io/HdrHistogram/plotFiles.htmlを使用できます 。 また、複数のhdrmファイルを比較するのにも便利です（たとえば、異なるブートシステム中または異なるサーバーから）。









プログラムのパフォーマンスのグラフ（たとえば、http応答の遅延）と受信したhdr-diagramを比較すると、システム全体が特定の期間でゆっくりと動作したのか、プログラムだけで動作したのかがわかります。







jhiccupは別のプロセスとして実行しました。 別の方法は、プログラムとともにjavaagentを実行することです。 







 java -javaagent:jHiccup.jar="-d 0 -i 1000 -l hiccuplog -c" MyProgram.jar -a -b -c


この場合、jhiccupが起動し、プログラム実行時間全体の遅延に関する情報を保存します。







これら2つの起動方法には1つの重要な違いがあります。 最初のケースでは、jHiccupは同じJVM上の別のJVMで実行されます。 つまり、2番目のケースでは、メインアプリケーションが実行されているJVMの作業に関連する遅延（たとえば、GCの一時停止）が表示されます。







jHiccupPlotter.xlsファイルでは、SLA線をチャートに追加できます。









SLAには2つの便利なアプリケーションがあります。









More articles:


All Articles