これは非常に興味深い質問であり、jHiccup の珍しいプロファイルでもあります。大規模な銀行で働いていると、通常、複雑なアプリケーションのマルチモーダル jHiccup 曲線が見られます。20% から 99.999% のトランザクションがたどる単一のパスがあるように見えます。これは驚くべきことであり、多くの人がエミュレートしたいと考えています (57usec をもっと小さくしたいと思うかもしれませんが)。これには非常に多くの原因が考えられるため、CPU 周波数、NIC レイテンシ、コンテキスト スイッチ コスト、同期書き込みコスト、スレッド スケジューリングの公平性など、57usec の数値をシフトできる変数を見つけて問題を分割することがおそらく最も効果的です。
より深く掘り下げるためにできることはたくさんあります。
分析 - あなたの「パーセンタイル分布によるしゃっくり」曲線がいかにフラットで、90% を下回っていることに驚きました。これは、約 57 マイクロ秒の単一の非常に一般的な一時停止イベントがあることを示唆しています。バケットのサイズと横軸を小さくするとどうなりますか?一時停止が均一、通常、二項、または定期的に分布しているかどうかがわかりますか? 10GB使ってる？あなたのアプリは、ワークロードとコンテキスト スイッチングの間に非常に一定の相関関係を示していますか (0.85 r-2 乗以上)?
いくつかのノブを微調整して、57micro ポーズのサイズが変化するかどうかを確認できます。これは、針がいずれかの方向に動くのを見るための微調整を改善するための微調整ではないことに注意してください。irq_balancer を無効にしても効果がなかったとおっしゃいましたが、一時停止のサイズが変わったのでしょうか? CPU周波数が影響するかどうかをテストすることから始めます。E5-2690 で実行している場合、E5-2650 で同じまたは異なる遅延が見られますか? 多様なハードウェアを持っていない場合は、max cset/turbo 設定を変更することでこれを実現できます。また、ネットワーク操作の NIC バッチ処理のバケット サイズを変更するために、NIC の IRQ 統合設定を調整してみます。どちらも針を動かさない場合は、それが単純な NIC の遅延または CPU の影響ではないことがわかります。
同じように、RHEL 5 メモリ バリア バグ、より高速なコンテキスト スイッチ、および異なるプロセス スケジューリング フェアネス動作を備えた古いカーネルでも実行してみます。https://github.com/tsuna/contextswitchのようなツールは、このようなものを特徴付けることができます。一時停止の 57 マイクロ振幅をシフトする変数を特定すると、そこに 75% 到達します。
また、現在 Oracle JVM を使用している場合は、Zing を使用してみて、それが何か変化するかどうかを確認することもできます。
何が起こるか教えてください。
ピーター
とおりです。これらの結果は、SUSE SLERT 112.6.33カーネルPREEMPTRT、Intel i5、4gメモリを搭載したマシンで得られたものです。プロセスは、CPUシールド（3つの論理プロセッサが分離された）および99の優先度（FIFO）で実行されていました。この57mcsのレイテンシーはどこから来ているのだろうか。アプリケーションは非常に簡単です。これはネットワーク注文処理システムであるため、TCPパケットフィードを解析し、単純なビジネスロジックを実行します。GCなし、同期化、シングルスレッドです。