RabbitMQ (beam.smp) et un problème de charge de mémoire/CPU élevé
j'ai une boîte debian qui exécute des tâches avec celery et rabbitmq pendant environ un an. Récemment, j'ai remarqué que des tâches n'étaient pas traitées, alors je me suis connecté au système et j'ai remarqué que celery ne pouvait pas se connecter à rabbitmq. J'ai redémarré rabbitmq-server et même si celery ne se plaignait plus, il n'exécutait plus de nouvelles tâches maintenant. La chose étrange était que rabbitmq dévorait ressources processeur et mémoire comme un fou. Redémarrer le serveur ne résoudrait pas le problème. Après avoir passé quelques heures cherchant une solution en ligne en vain, 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 celery recommence à se plaindre qu'il ne peut pas se connecter à 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 question:
rabbitmq a recommencé à enfler sans cesse cpu et prenant lentement en charge toute la ram 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
mise à JOUR: Il semble que le problème a été résolu lors de l'installation de la dernière version de rabbitmq (3.3.4-1) de rabbitmq.com dépôt. À l'origine, J'en avais installé un (2.8.4) dans les dépôts Debian. Jusqu'à présent rabbitmq-serveur fonctionne doucement. Je mettrai à jour ce post si le problème revient.
mise à JOUR: Malheureusement, après environ 24 heures, le problème est réapparu lorsque rabbitmq a arrêté et redémarré le processus le ferait consommer des ressources jusqu'à ce qu'il ferme à nouveau en quelques minutes.
4 réponses
finalement j'ai trouvé la solution. Ces billets ont aidé à comprendre cela. RabbitMQ sur EC2 Consommer des Tonnes de CPU 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 de /var/lib/rabbitmq/mnesia/rabbit/ , j'ai redémarré rabbit et ça marche très bien. maintenant.
ma solution était de désactiver le stockage des résultats avec CELERY_IGNORE_RESULT = True dans le fichier de configuration de Celery pour s'assurer que cela ne se reproduise plus.
Vous pouvez également réinitialiser la file d'attente:
sudo service rabbitmq-server start
sudo rabbitmqctl stop_app
sudo rabbitmqctl reset
sudo rabbitmqctl start_app
vous pourriez avoir besoin d'exécuter cette commande juste après le redémarrage si votre système ne répond pas.
vous épuisez les ressources de mémoire à cause de celery, j'ai eu un problème similaire et c'était un problème avec les files d'attente utilisées par celery backend résultat.
vous pouvez vérifier combien de files d'attente il y a en utilisant la commande rabbitmqctl list_queues, attention si ce nombre augmente pour eve. Dans ce cas, vérifiez votre utilisation de céleri.
à propos de celery, si vous ne recevez pas les résultats comme des événements asycroniques dont configurer un backend pour stocker ceux inutilisés résultats.
j'ai connu un problème similaire et il s'est avéré être en raison de certaines applications de client rogue RabbitMQ. Le problème semble avoir été que, en raison d'une erreur non-traitée, l'application voyou essayait en permanence d'établir un lien avec le courtier RabbitMQ. Une fois que les applications client ont redémarré, tout est redevenu normal (depuis que l'application a cessé de fonctionner et d'essayer de faire une connexion à RabbitMQ dans une boucle sans fin)