erlang - RabbitMQ(beam.smp) y problema de carga alta de CPU/memoria

debian celery

Question

Tengo una caja Debian ejecutando tareas con apio y rabbitmq durante aproximadamente un año. Recientemente noté que las tareas no estaban siendo procesadas, así que me conecté al sistema y noté que el apio no se podía conectar con rabbitmq. Reinicié el servidor rabbitmq y aunque el apio ya no se quejaba, no estaba ejecutando nuevas tareas ahora. Lo curioso fue que rabbitmq estaba devorando recursos de CPU y memoria como locos. Reiniciar el servidor no resolvería el problema. Después de pasar un par de horas buscando soluciones en línea en vano, decidí reconstruir el servidor.

Reconstruí el nuevo servidor con Debian 7.5, rabbitmq 2.8.4, apio 3.1.13 (Cipater). Durante aproximadamente una hora más o menos todo funcionó maravillosamente otra vez hasta que el apio comenzó a quejarse nuevamente de que no se puede conectar con 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...

Reinicié el service rabbitmq-server start y la misma ganancia de problema:

rabbitmq comenzó de nuevo hinchándose golpeando constantemente en la CPU y tomando lentamente todas las ram y swap:

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

Aquí está el resultado en el 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},

Algunas entradas 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

ACTUALIZACIÓN: Parece que el problema se resolvió cuando se instaló la versión más nueva de rabbitmq (3.3.4-1) del repositorio de rabbitmq.com. Originalmente tenía uno instalado (2.8.4) de los repositorios de Debian. Hasta ahora, rabbitmq-server está funcionando sin problemas. Actualizaré esta publicación si vuelve el problema.

ACTUALIZACIÓN: Desafortunadamente, después de aproximadamente 24 horas, reapareció el problema donde rabbitmq se cerró y reiniciar el proceso haría que consumiera recursos hasta que se apaga nuevamente en minutos.

Answer 1

Experimenté un problema similar y resultó ser debido a algunas aplicaciones de cliente robadas de RabbitMQ. El problema parece haber sido que, debido a un error no solucionado, la aplicación no autorizada intentaba continuamente establecer una conexión con el intermediario RabbitMQ. Una vez que las aplicaciones cliente se reiniciaron, todo volvió a la normalidad (ya que la aplicación dejó de funcionar mal y allí dejó de intentar conectarse con RabbitMQ en un bucle infinito)

Answer 2

Finalmente encontré la solución. Estas publicaciones ayudaron a resolver esto. RabbitMQ en EC2 consumiendo toneladas de CPU y https://serverfault.com/questions/337982/how-do-i-restart-rabbitmq-after-switching-machines

Lo que sucedió fue que rabbitmq se aferraba a todos los resultados que nunca se liberaron hasta el punto en que se sobrecargaron. Borré todos los datos obsoletos en /var/lib/rabbitmq/mnesia/rabbit/ , reinicié el conejo y funciona bien ahora.

Mi solución fue desactivar el almacenamiento de resultados junto con CELERY_IGNORE_RESULT = True en el archivo de configuración de CELERY_IGNORE_RESULT = True para asegurar que esto no vuelva a ocurrir.

Answer 3

También puedes restablecer la cola:

sudo service rabbitmq-server start
sudo rabbitmqctl stop_app
sudo rabbitmqctl reset
sudo rabbitmqctl start_app

Es posible que necesite ejecutar estos comandos justo después de reiniciar si su sistema no responde.

Answer 4

Usted está agotando los recursos de memoria debido al apio, tuve un problema similar y fue un problema con las colas utilizadas por el resultado del fondo de apio.

Puedes verificar cuántas colas hay usando el comando rabbitmqctl list_queues, presta atención si ese número crece por la noche. En ese caso, revisa tu uso de apio.

Acerca del apio, si no obtiene los resultados como eventos poco llamativos, no configure un back-end para almacenar esos resultados no utilizados.