1

アプリのログを処理するためにRabbitMQを使用しています（Windowsサーバー2008のインストール）。アプリは交換にメッセージを送信します。メッセージを転送する専用のキューがあります。次に、Windows サービスをそのキューに接続し、メッセージを取り出して DB に永続化します。ストリームをラッチするためにリアルタイムで交換に接続する n 数のクライアントがあるため、一度に n 数の接続があります。これらのクライアントの一部は、コードで接続を Close() しない可能性があります。多くのクライアントは長時間接続しています。

メッセージがキューから取り出されると、メッセージは自動的に確認応答されるため、未確認のメッセージがキューにありません。しかし、ラビットの記憶は時間の経過とともに成長しているのを見ています。最初にオンにしたときは32K程度で始まり、しきい値を超えて着信接続をブロックするまで忍び寄ります.

.NET クライアントと Java クライアントの両方を持っていますが、どちらも自動応答です。

ドキュメントを読んでも、Rabbit がどのようにメモリを使用しているかについての説明は見当たりませんでした。つまり、時間の経過とともにメモリが膨張する理由がわかりません。メッセージが引き離されて承認されているということは、Rabbit がこれ以上それを保持していないため、関連するメモリを解放して、安定したメモリ使用プロファイルを引き起こしていることを意味しているように思えます。

Rabbit のメモリ ダイヤルをいじっても、どれだけ効果があるかわかりません。

私の推測では、時間の経過とともにメモリが増加する原因となっているクライアントで何か間違ったことをしているのですが、それがなぜなのかはわかりません。

 why does Rabbit memory usage creep up when no messages are kept on any queues? 

 what coding practices could cause the RabbitMQ server to 
 retain (and grow) memory?
4

1 に答える 1

1

おそらく、交換にバインドされた他のキューを持っている可能性はありますか? 交換の下のRabbit管理ページを確認し、交換をクリックして、それにバインドされたキューを確認します。クライアントの 1 人が交換を宣言するときに、名前のない (システムでランダムに名前が付けられた) キューを誤って交換にバインドし、メッセージがそこに積み重なっている可能性があります。

他に確認すべきことは QoS 設定です。QoS をデフォルト (無限) のままにしておくと、Rabbit はクライアントが保持しているメッセージの数に関係なく、すぐにメッセージをクライアントに送信します。これにより、どのクライアントがどのメッセージをサーバーに持っているか、クライアントに大きなバッファーがあるなど、多くの簿記が発生します。

QoS プリフェッチ制限をもっと妥当な値 (100 など) に設定してください。そうすれば、100 万のメッセージがあり、プリフェッチが 100 のクライアントが 1 つしかない場合、Rabbit はクライアントに 100 だけを送信し、残りの 999900 を保持します。サーバー上のディスク上にあり、ほとんど多くのメモリを使用しません。

これがアプリケーションのメモリ膨張の大きな原因でしたが、プリフェッチに対処したので、すべて問題ありません。

于 2013-01-17T19:23:52.187 に答える