RabbitMQ (beam.smp) et problème de charge mémoire / processeur élevée
J'ai une boîte Debian exécutant des tâches avec le céleri et le lapin pendant environ un an. Récemment, j’ai remarqué que les tâches n’étaient pas traitées, j’ai ouvert une session sur le système et j’ai constaté que le céleri ne pouvait pas se connecter à rabbitmq. J'ai redémarré rabbitmq-server et même si le céleri ne se plaignait plus, il n'exécutait pas de nouvelles tâches maintenant. La chose étrange était que rabbitmq dévorait cpu et ressources de mémoire comme un fou. Redémarrer le serveur ne résoudrait pas le problème. Après avoir passé quelques heures à chercher une solution en ligne sans succès, j'ai décidé de reconstruire le serveur.
J'ai reconstruit un nouveau serveur avec Debian 7.5, rabbitmq 2.8.4, céleri 3.1.13 (Cipater). Pendant environ une heure, tout a fonctionné à merveille jusqu'à ce que le céleri recommence à se plaindre de ne pas pouvoir se connecter au rabbitmq!
[2014-08-06 05:17:21,036: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**@127.0.0.1:5672//: [Errno 111] Connection refused.
Trying again in 6.00 seconds...
J'ai redémarré rabbitmq service rabbitmq-server start et même problème:
rabbitmq a recommencé à gonfler et cogner constamment sur l'unité centrale, prenant lentement tout le bélier et l'échange
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21823 rabbitmq 20 0 908m 488m 3900 S 731.2 49.4 9:44.74 beam.smp
Voici le résultat sur rabbitmqctl status:
Status of node 'rabbit@li370-61' ...
[{pid,21823},
{running_applications,[{rabbit,"RabbitMQ","2.8.4"},
{os_mon,"CPO CXC 138 46","2.2.9"},
{sasl,"SASL CXC 138 11","2.2.1"},
{mnesia,"MNESIA CXC 138 12","4.7"},
{stdlib,"ERTS CXC 138 10","1.18.1"},
{kernel,"ERTS CXC 138 10","2.15.1"}]},
{os,{unix,linux}},
{erlang_version,"Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:30] [kernel-poll:true]\n"},
{memory,[{total,489341272},
{processes,462841967},
{processes_used,462685207},
{system,26499305},
{atom,504409},
{atom_used,473810},
{binary,98752},
{code,11874771},
{ets,6695040}]},
{vm_memory_high_watermark,0.3999999992280962},
{vm_memory_limit,414559436},
{disk_free_limit,1000000000},
{disk_free,48346546176},
{file_descriptors,[{total_limit,924},
{total_used,924},
{sockets_limit,829},
{sockets_used,3}]},
{processes,[{limit,1048576},{used,1354}]},
{run_queue,0},
Quelques entrées de/var/log/rabbitmq:
=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
write_threshold}
=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
write_threshold}
=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
write_threshold}
=WARNING REPORT==== 8-Aug-2014::00:11:35 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
write_threshold}
=WARNING REPORT==== 8-Aug-2014::00:11:36 ===
Mnesia('rabbit@li370-61'): ** WARNING ** Mnesia is overloaded: {dump_log,
write_threshold}
=INFO REPORT==== 8-Aug-2014::00:11:36 ===
vm_memory_high_watermark set. Memory used:422283840 allowed:414559436
=WARNING REPORT==== 8-Aug-2014::00:11:36 ===
memory resource limit alarm set on node 'rabbit@li370-61'.
**********************************************************
*** Publishers will be blocked until this alarm clears ***
**********************************************************
=INFO REPORT==== 8-Aug-2014::00:11:43 ===
started TCP Listener on [::]:5672
=INFO REPORT==== 8-Aug-2014::00:11:44 ===
vm_memory_high_watermark clear. Memory used:290424384 allowed:414559436
=WARNING REPORT==== 8-Aug-2014::00:11:44 ===
memory resource limit alarm cleared on node 'rabbit@li370-61'
=INFO REPORT==== 8-Aug-2014::00:11:59 ===
vm_memory_high_watermark set. Memory used:414584504 allowed:414559436
=WARNING REPORT==== 8-Aug-2014::00:11:59 ===
memory resource limit alarm set on node 'rabbit@li370-61'.
**********************************************************
*** Publishers will be blocked until this alarm clears ***
**********************************************************
=INFO REPORT==== 8-Aug-2014::00:12:00 ===
vm_memory_high_watermark clear. Memory used:411143496 allowed:414559436
=WARNING REPORT==== 8-Aug-2014::00:12:00 ===
memory resource limit alarm cleared on node 'rabbit@li370-61'
=INFO REPORT==== 8-Aug-2014::00:12:01 ===
vm_memory_high_watermark set. Memory used:415563120 allowed:414559436
=WARNING REPORT==== 8-Aug-2014::00:12:01 ===
memory resource limit alarm set on node 'rabbit@li370-61'.
**********************************************************
*** Publishers will be blocked until this alarm clears ***
**********************************************************
=INFO REPORT==== 8-Aug-2014::00:12:07 ===
Server startup complete; 0 plugins started.
=ERROR REPORT==== 8-Aug-2014::00:15:32 ===
** Generic server rabbit_disk_monitor terminating
** Last message in was update
** When Server state == {state,"/var/lib/rabbitmq/mnesia/rabbit@li370-61",
50000000,46946492416,100,10000,
#Ref<0.0.1.79456>,false}
** Reason for termination ==
** {unparseable,[]}
=INFO REPORT==== 8-Aug-2014::00:15:37 ===
Disk free limit set to 50MB
=ERROR REPORT==== 8-Aug-2014::00:16:03 ===
** Generic server rabbit_disk_monitor terminating
** Last message in was update
** When Server state == {state,"/var/lib/rabbitmq/mnesia/rabbit@li370-61",
50000000,46946426880,100,10000,
#Ref<0.0.1.80930>,false}
** Reason for termination ==
** {unparseable,[]}
=INFO REPORT==== 8-Aug-2014::00:16:05 ===
Disk free limit set to 50MB
PDATE: On dirait que le problème a été résolu lors de l'installation de la dernière version de rabbitmq (3.3.4-1) installée dans le référentiel rabbitmq.com. A l'origine, j'en avais un installé (2.8.4) à partir de référentiels Debian. Jusqu'à présent, rabbitmq-server fonctionne correctement. Je mettrai à jour ce post si le problème revient.
PDATE: Malheureusement, après environ 24 heures, le problème est réapparu. Rabbitmq s'est arrêté et le processus redémarré lui ferait consommer des ressources jusqu'à ce qu'il s'arrête de nouveau en quelques minutes.
Finalement j'ai trouvé la solution. Ces messages ont aidé à comprendre cela. RabbitMQ sur EC2 consommant des tonnes de CP et https://serverfault.com/questions/337982/how-do-i-restart-rabbitmq-after-switching-machines
Ce qui s’est passé, c’est que rabbitmq s’est accroché à tous les résultats qui n’ont jamais été libérés au point de devenir surchargés. J'ai effacé toutes les données périmées dans /var/lib/rabbitmq/mnesia/rabbit/, lapin redémarré et cela fonctionne bien maintenant.
Ma solution consistait à désactiver le stockage des résultats en même temps que CELERY_IGNORE_RESULT = True dans le fichier de configuration du céleri pour s’assurer que cela ne se reproduise plus.
Vous pouvez également réinitialiser la file d'attente:
Avertissement: Ceci efface toutes les données et la configuration! Utilisez avec prudence.
Sudo service rabbitmq-server start
Sudo rabbitmqctl stop_app
Sudo rabbitmqctl reset
Sudo rabbitmqctl start_app
Vous devrez peut-être exécuter ces commandes juste après le redémarrage si votre système ne répond pas.
Vous manquez de ressources de mémoire à cause du céleri. J'ai un problème similaire. Il s’agissait d’un problème de files d’attente utilisées par le résultat principal du céleri.
Vous pouvez vérifier le nombre de files d'attente utilisant la commande rabbitmqctl list_queues. Faites attention si ce nombre augmente pour la veille. Dans ce cas, vérifiez votre utilisation de céleri.
En ce qui concerne le céleri, si vous n'obtenez pas les résultats sous forme d'événements asynchrones, ne configurez pas de serveur pour stocker ces résultats inutilisés.
J'ai rencontré un problème similaire, dû à certaines applications clientes non fiables de RabbitMQ. Le problème semble avoir été dû au fait qu’une erreur non gérée a permis à l’application non autorisée d’essayer en permanence de se connecter au courtier RabbitMQ. Une fois que les applications clientes ont été redémarrées, tout est revenu à la normale (depuis que l'application a cessé de fonctionner et qu'il n'y a plus de tentative de connexion à RabbitMQ dans une boucle sans fin)