1

インターネットを介して多数のクライアントに多数の非常に小さなメッセージを配信するために、(ほぼ) リアルタイムの Netty サーバーを設計しています。内部では、できるだけ早くテストを行ってください。10,000 のクライアントを簡単に処理できることがわかりましたが、現在、遅延や帯域幅などが非常に大きく変化するインターネットを経由しようとしているため、恐ろしい outOfMemory に遭遇しています。 2ギガのRAMでも問題。

さまざまな回避策 (ソケット スタック サイズを小さく設定する、最高水準点と最低水準点を設定する、古すぎるものをキャンセルする) を試しましたが、少しは役に立ちますが、少ししか役に立たないようです。大幅な遅延なしに大量の小さなメッセージを送信するために Netty を最適化する良い方法は何でしょうか? また、メッセージの大部分は、届かなくても特に気にしない 1 種類のメッセージのみで構成されています。私は UDP を使用しますが、クライアントを制御しないため、実際には可能ではありません。他のメッセージに影響を与えることなく、この種のメッセージだけに別のタイムアウトを設定することは可能ですか?

あなたが提供できる洞察は大歓迎です。

4

3 に答える 3

0

サブスクリプション ストリームが一定であるかバーストであるかはわかりません。また、クライアントがサポートしなければならない 1 秒あたりの最小メッセージ数があるかどうかについても言及していません。

私は Redis について何も知らないので、次のいずれかが実用的ですか?

  • 気にしないメッセージについては、channel.isWritable() == false の場合、すぐに破棄します。残念ながら、Netty の送信バッファにあるメッセージをキャンセルする方法がわかりません。いずれにせよ、TCP 送信バッファーに渡されたメッセージをキャンセルすることはできないため、実際には依存するものではありません。
  • サブスクリプションから最も遅いクライアントの速度までの受信が遅い。
  • 対応できないクライアントを特定し (書き込みタイムアウト ハンドラを使用する可能性があります)、速度を落とすことができる別のサブスクリプションにそれらを移動します。パブリッシュされたメッセージを両方のサブスクリプションに複製します。
  • 異なるサブスクリプション間でクライアントに送信するメッセージを分割できますか? クライアントが重要でないメッセージについていけない場合は、購読を解除してください。

平均送信レートがクライアントが時間の経過とともにサポートできるよりも高い場合、最大許容スループットを減らすために要件の変更を交渉する以外に解決策はありません。

于 2012-09-25T09:36:15.163 に答える
0

負荷分散アプローチを検討することをお勧めします。ハードウェアとソフトウェアの両方を使用して、分散システム全体にワークロードを分散するために使用されます。システムに何が適しているかの詳細は、ハードウェアのアップグレードなどを含むいくつかの要因によって異なります。確かに、2GB の RAM はサーバー 10,000 ユーザーにはかなり小さいので、この制限を増やす必要があります。

于 2012-09-24T15:02:03.710 に答える
0

通常、outOfMemory が表示される場合は、スレッド ダンプ ツールを使用してスレッドをダンプできます。または、jvirtualvm や jconsole などを使用して、どのクラスが GC されずにメモリを消費し続けているかを調べます。最近の 64 ビット マシンでは 2Gigs は大きくありません。OOM にヒットしないかどうかを確認するために、それを 3 または 4G に大きくしてみてください。LAN で 10k 接続を簡単に処理できる場合は、netty ハンドラーに少し遅延を追加してみてください。何が起こるかを確認してください。

于 2012-09-24T13:56:53.347 に答える