Le fait que la plus grande partie de la mémoire utilisée est associée à aucun message particulier (la partie « références binaires » de votre capture d'écran), suggère cette mémoire est utilisée par exploitation ressources système non directement gérées par RabbitMQ. Mon plus grand suspect serait des connexions ouvertes.
Pour tester cette théorie, vous pouvez exécuter netstat et voir si vous obtenez des résultats similaires (en supposant que vous exécutez rabbitmq sur le port par défaut - 5672):
[email protected]:~# 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)
⋮
La partie intéressante est la dernière colonne montrant "Minuterie éteinte". Cela indique que cette connexion n'utilise pas les keepalives, ce qui signifie qu'ils vont simplement balancer là-bas en train de manger des ressources si le client meurt sans avoir la chance de les fermer gracieusement.
Il y a deux façons d'éviter ce problème:
TCP KeepAlives
Ceux-ci sont traitées par le noyau. Chaque fois qu'une connexion ne voit aucun paquet pendant un certain temps, le noyau essaie d'envoyer des sondes pour voir si l'autre côté est toujours là. Étant donné que les valeurs par défaut du délai Linux (par exemple 4.12) sont assez élevées (7200 secondes + 9 sondes toutes les 75 secondes> 2 heures), rabbitmq does not use them by default.
Pour les activer, vous devez l'ajouter à votre rabbitmq.config:
[
{rabbit, [
⋮
{tcp_listen_options,
[
⋮
{keepalive, true},
⋮
]
},
⋮
]},
⋮
].
et probablement abaisser les délais d'attente des valeurs plus sensibles. Quelque chose comme cela pourrait fonctionner (mais bien sûr YMMV):
[email protected]:~# sysctl net.ipv4.tcp_keepalive_intvl=30
[email protected]:~# sysctl net.ipv4.tcp_keepalive_probes=3
[email protected]:~# sysctl net.ipv4.tcp_keepalive_time=60
Protocole d'application des battements de coeur
Ceux-ci sont traitées par les protocoles de messagerie réelle (par exemple AMQP, STOMP, MQTT), mais exigent que le client Opt dans. Étant donné que chaque protocole est différent, vous devez vérifier le documentation pour le configurer dans vos applications client.
Conclusion
L'option la plus sûre, du point de vue d'éviter les ressources ballants, sont keepalives TCP, puisque vous ne devez pas compter sur vos applications clientes se comportent. Cependant, ils sont moins polyvalents et, s'ils sont mal configurés sur un système à débit élevé mais «en rafale», ils peuvent entraîner de moins bonnes performances, car les faux positifs provoquent des reconnexions.
Les Hearbeats de protocole d'application sont l'option la plus fine si vous devez éviter ce problème tout en conservant les performances de votre système, mais ils nécessitent plus de coordination, dans le sens où les clients doivent choisir et choisir leurs propres délais. Étant donné que vous ne pouvez jamais être sûr à 100% que vos clients ne mourront pas sans fermer les connexions, activer les keepalives TCP en tant que solution de repli (même avec des délais plus longs) pourrait aussi être une bonne idée.
Une résolution ici? Nous voyons la même chose dans 3.6.10. –
Pour le moment, nous l'avons juste cloué à l'un de nos scripts PHP, mais nous avons encore besoin de plus d'investigations sur ce ... peut-être la bibliothèque AMQP ou similaire – Onitlikesonic