15

Java で書かれた低遅延取引システム (フィード ハンドラー、分析、注文入力) があります。TCP と UDP を広く使用し、Infiniband やその他の非標準ネットワークは使用しません。

このシステムを展開するためのさまざまな OS または OS 構成のトレードオフについてコメントできる人はいますか? 最新の価格フィードに遅れずについていくためにスループットが重要であることは明らかですが、レイテンシーは私たちの最優先事項です。

Java を作成したので、Solaris は自然な候補のように思えます。Sparc または x64 プロセッサを使用する必要がありますか?

RHEL と SLERT について良いことを聞いたことがあります。これらは、ベンチマークで使用するのに適した Linux のバージョンです。

上記の OS に対して Windows をテストした人はいますか? それともついていけないと思われますか？

Java と C++ の議論は別のスレッドに譲りたいと思います。

4

8 に答える 8

5

トレーディング環境では、低遅延に加えて、おそらく一貫性と遅延が懸念されるため、GC一時停止の影響を可能な限り減らすことに焦点を当てることで、さまざまなOSの選択よりも多くのメリットが得られる可能性があります。

ただし、マイクロ秒ごとに重要な環境で取引システムを使用することを計画している場合は、現在の世代のVMから得られる一貫性の欠如に実際に対応する必要があります-それらのいずれも（リアルタイムを除く）保証しません低マイクロ秒のGCが一時停止します。もちろん、このレベルでは、OSアクティビティと同じ問題（プロセスのプリエンプション、割り込み処理、ページフォールトなど）が発生します。この場合、Linuxのリアルタイムバリアントの1つが役に立ちます。

于 2009-12-23T17:30:05.167 に答える
2

Windowsだからといって、Windowsを除外するつもりはありません。過去数年間の私の経験では、Sun JVM の Windows バージョンは通常、同じハードウェア上の Linux や Soaris x86 とは対照的に、最も成熟したパフォーマンスでした。Solaris SPARC 用の JVM も良いかもしれませんが、x86 上の Windows では、より少ない費用でより多くのパワーを得ることができると思います。

于 2009-12-23T17:47:58.447 に答える
1

おそらく、ガベージ コレクションがオペレーティング システムよりもかなり前にレイテンシを引き起こすことを心配するでしょう。それを調整することをまったく検討しましたか？

時間をかけてさまざまな OS を試してみたいと思うなら、Solaris 10 と NetBSD、そしておそらく Linux 版を試してみます。

32 ビットと 64 ビットのアーキテクチャを試してみます。64 ビットでは、より大きなヒープ アドレス空間が得られますが、メモリの各ビットのアドレス指定に時間がかかります。

アプリケーションのプロファイルを作成し、ボトルネックがどこにあるかを知っていると仮定しています。GC についてのコメントによって、あなたはそれをしました。その場合、アプリケーションが CPU バウンドであってはならず、チップ アーキテクチャが主要な関心事であってはなりません。

于 2009-12-23T15:29:04.070 に答える
0

マネージ コード環境とリアルタイム処理がうまく調和しているとは思えません。待ち時間が本当に気になる場合は、マネージ コードによって課されたレイヤーを削除してください。これは Java 対 C++ の議論ではなく、Java/C#/... 対 C/C++/FORTRAN/... の議論であり、これは有効な設計上の議論であると私は信じています。

はい、私は FORTRAN を意味します。FORTRAN 基盤を使用して、多くのほぼリアルタイムのシステムを実行しています。

于 2009-12-23T15:51:15.230 に答える
0

より高速なネットワーク ファブリックの可用性を考慮すると、オペレーティング システムまたは構成可能の選択は完全に冗長です。

ToE NIC を備えた 10GigE、または 4X QDR (40Gbs) InfiniBand のより高速なソリューションですが、標準のイーサネット インターフェイスとルーティングを提供するIPoIBを備えています。

于 2010-11-30T08:54:23.467 に答える
0

待ち時間を管理する 1 つの方法は、いくつかの JVM で作業を小さなヒープに分割することです。これにより、ワールド ガベージ コレクションの停止が発生してもそれほど時間がかからず、プロセスへの影響が少なくなります。

もう 1 つのアプローチは、十分なメモリを備えた JVM のクラスターをロードし、プロセスを割り当てて、遅延が気になる時間帯にワールド ガベージ コレクションが停止しないようにすることです (これが 24 時間年中無休のアプリでない場合)。時間外に JVM を再起動します。

可能性として、他の JVM 実装 (JRocket など) も検討する必要があります。もちろん、それらのいずれかが適切かどうかは、特定のアプリケーションに完全に依存します。

上記のいずれかがアプローチに関係する場合、OS の選択に影響します。たとえば、別の JVM 実装を使用する場合は、OS の選択が制限される可能性があり、クラスタリングを使用するか、アプリケーション用に複数の JVM を実行する場合は、効果的に管理するために基盤となるより優れた OS ツールが必要になる可能性があり、OS の選択にさらに影響を与えます。 .

于 2009-12-23T16:54:14.997 に答える