RabbitMQバイナリメモリ消費

Question

以下の画像（Rabbit 3.6.6-1）によると、「バイナリリファレンス」/ブレークダウンで同じメモリ使用量を示していない場合、「バイナリ」に使用されているメモリはどこにあるのでしょうか

誰でも啓発できますか？ 何かが "クリーンアップ"する必要があると思われます...しかし何ですか？

「バイナリ」のこの大きな消費も4つのキューとメッセージなしのマシン上で見ることができます

...

EDIT 17/07/2017：私たちは、これはという事実に主であることを発見した 私たちはrabbitmqへの複数の接続を開いたり閉じたりします。何らかの形でメモリをきれいに解放することはできません。

Answer 1

使用されるメモリの最大の部分は、特定のメッセージ（あなたのスクリーンショットの「バイナリ参照」の部分）に関連付けられていないという事実

は、このメモリは動作で使用されている示唆しますRabbitMQで直接管理されていないシステムリソース。私の最大の容疑者はオープンな接続だろう。

はこの理論をテストするには、 netstatを実行し、同様の結果（デフォルトのポートでのRabbitMQを実行していると仮定 - 5672）を取得するかどうかを確認することができます

root@rabbitmqhost:~# netstat -ntpo | grep -E ':5672\>' 
Active Internet connections (w/o servers) 
Proto Recv-Q Send-Q Local Address   Foreign Address   State  PID/Program name Timer 
tcp6  0  0 xxx.xxx.xxx.xxx:5672 yyy.yyy.yyy.yyy:57656 ESTABLISHED 27872/beam.smp off (0.00/0/0) 
tcp6  0  0 xxx.xxx.xxx.xxx:5672 yyy.yyy.yyy.yyy:49962 ESTABLISHED 27872/beam.smp off (0.00/0/0) 
tcp6  0  0 xxx.xxx.xxx.xxx:5672 yyy.yyy.yyy.yyy:56546 ESTABLISHED 27872/beam.smp off (0.00/0/0) 
tcp6  0  0 xxx.xxx.xxx.xxx:5672 yyy.yyy.yyy.yyy:50726 ESTABLISHED 27872/beam.smp off (0.00/0/0) 
⋮ 

興味深い部分は、最後の列の上映です"タイマーオフ"。これは、この接続がキープアライブを使用していないことを示しています。つまり、クライアントが正常に閉じることなく死んでしまった場合、リソースを浪費するだけです。

この問題を回避するには、2つの方法があります。

• TCPキープアライブこれらはカーネルによって処理され

• application protocol heartbeats

TCPキープアライブが。接続に一定時間パッケージがない場合、カーネルはプローブを送信して相手側がまだ存在するかどうかを確認しようとします。 現在のLinux（例えば4.12）のタイムアウトのデフォルト値は非常に高い（7200秒+ 9回のプローブ= 75秒> 2時間）ので、rabbitmq does not use them by default。それらを有効にするに

、あなたのrabbitmq.configにそれを追加する必要があります。

[ 
    {rabbit, [ 
    ⋮ 
    {tcp_listen_options, 
     [ 
     ⋮ 
     {keepalive,  true}, 
     ⋮ 
     ] 
    }, 
    ⋮ 
    ]}, 
    ⋮ 
]. 

、おそらくいくつかのより多くの実用的な値にタイムアウトを下げます。このような何かを（もちろんメーリングリストへの）働くかもしれない：

は

root@rabbitmqhost:~# sysctl net.ipv4.tcp_keepalive_intvl=30 
root@rabbitmqhost:~# sysctl net.ipv4.tcp_keepalive_probes=3 
root@rabbitmqhost:~# sysctl net.ipv4.tcp_keepalive_time=60 

アプリケーションプロトコルがハートビート

これらは、実際のメッセージング・プロトコル（例えばAMQP、STOMP、MQTT）で扱うが、opt-することをクライアントに要求されていますに。各プロトコルは異なるため、クライアントアプリケーションで設定するにはdocumentationをチェックする必要があります。あなたのクライアントアプリケーションが動作しに依存する必要がないので

結論

ダングリング資源を回避する観点から、最も安全なオプションは、、TCPキープアライブです。 しかし、それらはあまり汎用性がなく、ハイスループットであるがバースト的なシステムで誤って構成された場合、偽陽性が再接続を引き起こすため、パフォーマンスが低下する可能性があります。

システムのパフォーマンスを維持しながらこの問題を回避する必要がある場合、アプリケーションプロトコルヒアビートはより細かいオプションですが、クライアントが選択して自分の合理的なタイムアウトを選択するという点で、より調整が必要です。 クライアントが正常に接続を終了しないとクライアントが死ぬことは決してありませんので、TCPキープアライブをフォールバックとして有効にすると（タイムアウトを長くしても）良い考えになるかもしれません。