問題タブ [low-latency]

このリンクでは、次のように述べられています。

これらの一時停止は、ヒープを圧縮してスペースを解放するという必然的な要件の結果です。コレクターはさまざまな戦略を使用してこれらのイベントを遅らせますが、商用利用可能なすべてのコレクターで圧縮は避けられません。

アプリケーションのメモリ フットプリントを一定に保つ場合、GC コンパクションが発生する必要はないという印象を受けました。つまり、オブジェクトの追加と収集を続ける場合にのみ発生します。十分な空き領域がある十分な大きさのヒープがある場合、穴を作成していない (つまりゴミを生成していない) のに、なぜ圧縮する必要があるのでしょうか?

Java アプリケーションのメモリ フットプリントを一定に保つのは簡単ではないことは理解していますが、適切なプロファイリング ツール、ブートストラップ、規律があれば可能です。

では、一定のメモリ フットプリントがあれば、Java アプリケーションは GC によるレイテンシなしで、つまり GC の一時停止なしで実行できると仮定するのは合理的ではないでしょうか?

EDIT：一定のメモリフットプリントとは、steady stateAjay Georgeが述べたように、オブジェクトが作成または逆参照されない場合を意味します。オブジェクトを作成し続けると、最終的にメモリ不足になり、オブジェクトを逆参照し続けると、最終的に GC がトリガーされます。したがって、最終的な目標は、起動、ウォームアップ、完全な GC の実行を強制してから、運用時間の安定状態に入るということです。

私はのガベージ動作をプロファイリングしていますが、クラス内で初めてjava.lang.String文字列をインスタンス化するたびに、常にガベージが生成されるようです。誰かが理由を知っていますか？

出力：

収集：704336
収集：0

それはいいです。最初にガベージを作成し、その後のインスタンス化ではガベージを生成しません。

奇妙なことに、スーパークラスで文字列を強制的に作成しても、サブクラスで文字列を最初にインスタンス化したときに、サブクラスでガベージが作成されます。

出力：

収集：348648

なぜですか？

（ちなみに、これはMACとJDK 1.6.0_37で実行しています）

編集1：コードを少し変更して、文字列の内部化がここでの原因ではないことを明確にしました。少なくとも、そうであるようには見えません。

EDIT2：コード全体でStringをObjectに変更すると、同じガベージが発生するため、Javaでnewを介したオブジェクトの割り当てがどのように行われるかに関係していると思います。クラスに初めてオブジェクトを割り当てると、ガベージが発生します。2回目はしません。奇妙なことに、クラスごとです。

EDIT3：上記のコードで行っているように、GCにガベージ作成のためにアプリケーションのプロファイルを強制する方法について説明するブログ記事を書きました。

これが私のシナリオです。ソケットから読み取り、パケットの内容に基づいて、パケットを適切なキューに入れました。したがって、10 個のキューがある場合、適切なキューを選択するために 10 個の if-else-if または 10 ケースの switch ステートメントが存在します。したがって、最大 10 個の比較が可能です。

別の方法は、ブロードキャスター/サーバーに10個の異なるポートでブロードキャストするように依頼することです。各ポートからのフィードには、単一の特定のキューのパケットが含まれます。私の側では、別のスレッドを介して各ソケットをリッスンできます(またはスレッドを使用できます特定のポートのトラフィックが少ない/不均一な場合はプールします)。そのため、パケットが属するキューを選択する必要はありませんが、conext スイッチの現象が導入されました。

ここから先は、私の知性と技術的知識により、先へ進むことができなくなります。どのアプローチがより良いパフォーマンスを発揮するかについての啓発はありますか?

投機的評価 (別名、投機的実行) は、時折の手直し (非効率) を犠牲にして、低レイテンシーのコードを実現するための効果的なアプローチです。投機的評価は、現代のコンピューター アーキテクチャで一般的な低レベルの手法ですが、高レベルのプログラミング モデルでサポートできます (タイム ワープ プロトコル、時相論理、リアクティブ プログラミング モデルを参照)。

投機的評価が特に役立つと思われる場所の 1 つは、ライブ コーディングやゲームなどのオーディオのリアルタイム計算です。アイデアは単純です。オーディオ バッファーを投機的に満たしてバッファー アンダーランを防ぐことができますが、最後の瞬間の変更に対応する必要がある場合は、それらのバッファーを時々修正します。このような手法は、依然として不具合を起こす可能性があります。更新が遅れていると、前面が少し切り落とされる可能性があります。しかし、推測されたサウンドのほとんどはまだほとんど正しいはずなので、これは通常のアンダーランとは異なる (潜在的により優雅な) グリッチのモードです。

さて、私が疑問に思っているのは、どのオーディオ API またはライブラリが、既存のバッファに対するこれらの最後の瞬間の更新を最も効果的にサポートするかということです。私は健全なプログラミングの専門家ではありませんが、私が見たほとんどのサンプル コードは、バッファーへのコミットメントを想定しているようです。バッファを読み込んだ後にバッファにコミットしている場合、レイテンシとアンダーランのリスクとの間でトレードオフを行うしかありません。コミットメントを必要としないオーディオ API はどれですか?

私は HFT 取引ソフトウェアを書いています。私はすべてのマイクロ秒を気にします。今は C# で書いていますが、すぐに C++ に移行します。

そのようなコードを考えてみましょう

超低遅延ソフトウェアは「new」キーワードをあまり使用すべきではないと思うのでactions、次のフィールドに移動しました。

おそらく、「新しい」キーワードをまったく避けるようにする必要がありますか？事前に割り当てられたオブジェクトの「プール」を使用できます。

• どこまで行けばいいですか？
• 避けることがどれほど重要newですか？
• 構成のみが必要な事前割り当てオブジェクトを使用している間、何かを獲得できますか? （上記の例ではタイプと価格を設定）

これは超低遅延なので、可読性保守性などよりもパフォーマンスが優先されると仮定してください。

私のサイトでは、特定のAJAXファイル（UIの核心）の平均遅延（バックアップしていない場合など）が約150ミリ秒です。サーバーサイド/データベースのトリックをいくつか実行することで、これを約250ミリ秒から短縮しました。最後のトリックとして、実際のP​​HP / MySQL部分の現在の合計約30ミリ秒から、さらに10ミリ秒ほど短縮できると思います。ページ。

私はkeep-aliveを使用しているので、sslハンドシェイクはほぼ完全に機能しなくなったと思います（ただし、すぐにSPDYに移行したいので、最初のハンドシェイク後にどのように役立つかはわかりません）。

pingを実行すると、平均で約55ミリ秒になります。

ファイルの最初でMySQLに接続し、最後で閉じます。私はそれがおよそ10msの費用がかかるとかなり確信しています。

では、残りの約55ミリ秒はどこから来るのでしょうか。

これは完全に強迫的に見えるかもしれませんが、これは急速な動的ページネーションのためであり、遅延の各ミリ秒によって効果が大幅に低下します。

よろしくお願いします！

私は現在、自家製のインターフェイスライブラリで作成されたWebアプリを標準のExtJSMVCアプリケーションに変換するために取り組んでいます。ページの起動時に待ち時間が長くなるAjaxリクエストを除いて、すべてが正常に機能します。実際、私が呼び出すファイルは以前とそれほど変わりませんが、応答を返すために以前より3〜6秒長く待たなければならない場合があります。

調査の範囲を狭めるために、静的データ（単純なjson文字列）を返すようにコードを変更し、データベースの問題のオプションを排除しました。さらに、Google Chrome（[ネットワーク]パネル）で[Replay XHR]を使用すると、ほぼ瞬時に応答が返されることに気付きました。

このトピックについて支援するのは難しいと思いますが、誰かがすでにこの種の問題に遭遇していて、どこで調査すべきかについていくつかのアドバイスを共有できることを願っています。

観察

• レイテンシでソートされたリクエスト（ギャップは約500ms）：

  

• 開始時刻でソートされたリクエスト：

  

気づいてくれた Matthew Watson に感謝します。また、自分のコードを c++-linux に移植する予定であるため、「プラットフォームに依存しない」コードを好みます。

私の取引アプリケーションはほとんどロックフリーです。以下のコードは、ロックを使用する唯一の場所です。コードから始めましょう。かなり長いですが、繰り返し部分がたくさんあるので心配はいりません。簡単です。私の物事がどのように機能するかをよりよく示すために、すべての「繰り返し」部分を追加することを好みます。

私のコードでは、2 つの段階があります。Stage1更新段階であり、Stage2作業段階です。次のように、これら 2 つの段階をできるだけ早く切り替える必要があります。

• アップデートはありますか？番号
• アップデートはありますか？番号
• 更新されましたか？はい、注文が更新されました！アップデートを適用するStage2
• アップデートはありますか？番号
• アップデートはありますか？はい、注文を登録する必要があります! アップデートを適用するStage2
• アップデートはありますか？はい、取引が発生しました。更新を適用してください。Stage2

更新する必要はStage2ありませんが、後で適用できるように更新を「収集」し続ける必要があります。

そして重要なこと - これは非常にレイテンシが重要なコードであるため、最小限のレイテンシを実現するために 1 つのコアを「使用」することに同意します! したがって、更新が発生した場合は、できるだけ早く処理して実行する必要がありますStage2。

ですから、何を達成する必要があるのか​​ 、それをどのように実装したのかが明確になったことを願っています. ここで、私のコードがどれほど優れているかについて説明します。潜在的な問題がいくつか見られます。

• ロックがいっぱい！「ロックフリー」コードに置き換えることはできますか? CASか何かでスピンロック？
• CPU コアの 100% を占有している場合、レイテンシーに影響を与えずにCPU リソースを節約できますか?
• 余分な「スイッチ」を避けるために、.NET に「専用」コアを使用する (タスク アフィニティを設定する) ように指示できますか?
• あるスレッドからキューに追加し、別のスレッドからキューを読み取ります。それは問題になるでしょうか？キューへの追加と読み取りが不安定な場合は? キャッシュ更新の問題が原因で、読み取りスレッドがキューからの更新を認識しない可能性はありますか?

私が書いたものを改善する方法についての提案は大歓迎です、ありがとう!

upd は部分的に解決されました - 私が理解しているように、クエリをロックフリー (リング バッファ ベースの可能性が高いですか?) クエリに置き換える方が良いと思います..後で C++ バージョンのディスラプターを使用すると思います。また、この記事http://www.umbraworks.net/bl0g/rebuildall/2010/03/08/Running_NET_threads_on_selected_processor_coresを使用し、タスクを「固定」コアで実行されているスレッドに置き換えましたが、まだ「ビジー」を使用しています-spin"、おそらくもっとスマートなものを使用する必要がありますか?

Tomcat でページの応答時間をマイクロ最適化しています。ほとんどの場合、何度も更新すると応答時間が50 ミリ秒になりますが、ページが 1 秒または 2 秒間ヒットしないと、応答時間が跳ね上がります。500msまで。

ローカル、ローカルではなく、APR、NIO、JIO、静的または動的応答 (つまり、静的ファイルを提供するか、応答を動的に処理する) に関係なく、これと同じ動作を見てきました。これまでのところ、この動作が Tomcat で発生しないことはまだ確認していません(頻度に関係なく、400 ミリ秒未満で一貫しています)。

手がかりがあるかどうかを確認するために Visual VM も使用しました。

ある種のキープアライブだと思っていましたが、Apache Bench を実行すると、応答時間がさらに速くなります (サブ 50 ミリ秒) (明らかに、頻繁にヒットするため)。

では、Tomcat で頻繁に URL にヒットしないように低レイテンシーを維持するにはどうすればよいでしょうか? おそらく、この質問は ServerFault の方が適切でしょうか?

更新: Tomcat 6 の問題であるとほぼ確信しています。Tomcat 7 でテストしたと思っていましたが、再度テストしたところ問題はありませんでした (以下の結果を参照)。最新の Tomcat 6 でもまだこの問題があります。

Tomcat 6のab出力は次のとおりです (最大値に注意してください)。

abTomcat 7 の出力は次のとおりです。

Tomcat のバージョンだけが違います (同じマシン、同じ JDK など)。最新のTomcat 6でも問題ないと確信していましたが、最初のリクエストで同様のレイテンシーが発生しました。

私のHFT取引アプリケーションには、ネットワークからデータを受信する場所がいくつかあります。ほとんどの場合、これはデータを受信して​​処理するだけのスレッドです。以下はそのような処理の一部です：

このスレッドは、一度作成されると永久に機能します。このスレッドを特定のコアで実行するように構成する必要があるかどうか疑問に思いますか？最小のレイテンシが必要なので、コンテキストスイッチを避けたいと思います。コンテキストスイッチを避けたいので、同じプロセッサコアで同じスレッドを実行する方が良いでしょう？

私が最低のレイテンシーを必要としていることを考慮に入れると、それは正しいです：

• 「長時間実行」スレッドの大部分に「スレッドアフィニティ」を設定する方がよいでしょうか。
• 上記の例のスレッドに「スレッドアフィニティ」を設定する方がよいでしょうか。

上記のコードを今すぐc++に書き直して、これが重要な場合は後でLinuxに移植しますが、私の質問は言語やOSよりもハードウェアに関するものだと思います。