私たちは 2 つのデュアルノード ブローカーを運用しており、各ブローカーはまったく異なるキューとワークロードを持っています。各ボックスには、24 コア (H/T) 相当の Xeon E5645 @ 2.4GHz と 48GB RAM があり、ギガビット LAN で接続されており、遅延は最大 150μs で、RHEL 5.6、RabbitMQ 3.1、Erlang R16B を HiPE オフで実行しています。HiPE をオンにして試してみましたが、パフォーマンスへの顕著な影響はなく、非常にクラッシュしました。
メッセージ レートは、1,000/s から 1,400/s の範囲で、インとアウトの両方で上限に達したようです。これは、キューごとではなく、ブローカー全体です。コンシューマーを追加しても、全体的なスループットは向上しません。その特定のキューに、この明らかなリソースの「プール」のより大きなスライスを与えるだけです。
すべてのキューは、ブローカーを構成する 2 つのノード間でミラーリングされます。パブリッシャーとコンシューマーは、永続的な方法で両方のノードに等しく接続します。レートにも ADSL のような非対称性があることに気付きました。高い率でメッセージを発行できれば、配信率は 2 桁台後半に低下します。ミラーリングされていないキューを使用したテストでは、予想どおり、はるかに高いスループットが得られます。キューと Exchange は永続的ですが、メッセージは永続的ではありません。
状況を改善するために私たちができることを知りたいです。ボックスの CPU は問題ありません。ビームは 1 つのプロセスで 1.5 コアを使用し、別のプロセスでは 2 つのコアでそれぞれ 80% を使用します。ボックスの残りの部分は基本的にアイドル状態です。ユーザーランドで最大20GBのRAMを使用しており、残りはシステムキャッシュで満たされています。IO レートは問題ありません。ネットワークは問題ありません。
私たちができる Erlang/OTP チューニングはありますか? delegate_count はデフォルトの 16 ですが、これが何をするのかもう少し詳しく説明してもらえますか?