Gladys v4.70.0 (actualizado automáticamente mediante Watchtower)
Docker en Linux (Ubuntu), network_mode: host
Integración MQTT con múltiples dispositivos (Raspberry Pis)
Problema:
Después de que Watchtower actualizó automáticamente Gladys de v4.66.8 a v4.70.0, el contenedor comenzó a consumir ~60% de CPU constantemente – no solo al inicio, sino permanentemente.
gladys 59.72%
Los registros mostraron una inundación de errores al inicio:
NotFoundError: DeviceFeature mqtt:xxx not found
Estos parecen ser un problema de sincronización donde los mensajes retenidos de MQTT llegan antes de que Gladys haya cargado su caché de características de dispositivos. Sin embargo, incluso después de que los errores de inicio cesaron y los registros estaban limpios, la CPU se mantuvo en ~60%.
Solución:
Se degradó a v4.66.8 y se fijó la versión para evitar que Watchtower realice actualizaciones automáticas:
yaml
gladys:
image: gladysassistant/gladys:v4.66.8
labels:
com.centurylinklabs.watchtower.enable: "false"
```
Después de la degradación, la CPU bajó inmediatamente a ~4%.
```
gladys 3.90%
Pregunta:
¿Es este un problema conocido con v4.70.0? ¿Hay planes para corregir la regresión de CPU? Me gustaría actualizar eventualmente, pero no si vuelve a afectar el rendimiento.
¡Hola @bamboleate y bienvenido al foro!
Debes tener algo que no funciona bien, porque por mi parte no tengo problemas de CPU que se dispare desde la versión 4.70 (ni siquiera antes):
El pico de CPU es muy reproducible en mi caso. Aquí está el antes/después:
v4.70.0:
gladys 59.72%
v4.66.8 (misma máquina, misma configuración, mismo momento):
gladys 3.90%
Estoy ejecutando la integración MQTT con 3 Raspberry Pis (placas de relé + sensores). Sin Zigbee, sin Z-Wave, pero sí uso Node-RED.
Algo que noté en los registros al iniciar con v4.70.0:
NotFoundError: DeviceFeature mqtt:xxx not found
Esto se repite para cada característica de dispositivo MQTT en cada inicio – parece que los mensajes retenidos llegan antes de que la caché de dispositivos esté lista. ¿Podría esta inundación de errores estar causando el pico de CPU? ¿Quizás sea específico de las configuraciones MQTT?
Tu equipo parece estar bien, por mi parte estoy en un clúster Proxmox y Gladys está en un LXE (equivalente a una VM para simplificar) con 6 GB de RAM y 2 vCPU.
No soy un experto para un análisis detallado, desafortunadamente.
Sin embargo, en cuanto a la integración MQTT de Gladys, ¿usas la integración interna?
De lo que veo del mensaje de error, un (¿o varios?) dispositivo no es encontrado/reconocido, habría que ver con MQTT Explorer si está bien visible y si su configuración sigue siendo correcta en la integración MQTT de Gladys.
¡Hola @mutmut, gracias por las preguntas detalladas!
Sí, uso la integración interna de MQTT en Gladys.
En cuanto a los mensajes de NotFoundError: ya investigué esto a fondo. Los errores aparecen solo al inicio y son un problema de sincronización: el broker MQTT entrega mensajes retenidos antes de que Gladys haya terminado de cargar su caché de características de dispositivos. Después del inicio, los registros están completamente limpios y todos los dispositivos funcionan correctamente. Las Raspberry Pi publican correctamente, los temas son correctos y todo es visible en MQTT Explorer.
Los errores no son la causa de mis problemas: son un síntoma del tiempo de inicio. Y lo más importante: la CPU se mantiene en ~60% permanentemente, no solo durante la inundación de errores al inicio.
El punto clave es la comparación directa:
v4.70.0 → 60% de CPU constantemente, mismos errores al inicio
v4.66.8 → 4% de CPU constantemente, mismos errores al inicio (el problema de sincronización existe en ambas versiones)
Por lo tanto, algo cambió entre la v4.66.8 y la v4.70.0 que causa una regresión en el uso de la CPU, al menos en mi configuración con MQTT. Los errores al inicio son un problema separado (más antiguo).
Mi primer instinto me dice que es de la versión 4.70 porque antes tenía activado el watchtower y no me molesté en gestionar todas las versiones, pero cuando me encontré con el problema por primera vez, era la versión 4.70 y solo bajé bastante para no tener que lidiar tanto y simplemente hacer que funcione de nuevo.
PERO eventualmente instalaré todas las versiones para ayudarte a identificar el problema. Por supuesto, este fin de semana no estaré disponible, así que tomará un tiempo… Volveré aquí cuando sepa más.
¡GRACIAS por todo lo que haces y has hecho!
Hice la actualización gradual como sugeriste. Aquí están mis resultados:
v4.66.9 → CPU normal, sin problemas
v4.67.0 → CPU salta inmediatamente al ~57% y se queda ahí
Por lo tanto, el problema se introduce en v4.67.0.
El registro de cambios de esa versión solo muestra tres cambios:
Integración de Nuki
Copia de seguridad de Gladys Gateway DuckDB en conexión temporal a la base de datos
Actualización de la dependencia HAP a la última versión estable
No uso HomeKit/Apple Home, por lo que no puedo confirmar si la actualización de HAP es la culpable, pero parece el candidato más probable para un bucle de CPU.
Los registros muestran algo interesante. Hay una inundación de rechasos de Promesas no manejadas relacionadas con MQTT DeviceFeatures no encontrados:
NotFoundError: DeviceFeature mqtt:wozipi:07 no encontrado
NotFoundError: DeviceFeature mqtt:wozipi:10 no encontrado
NotFoundError: DeviceFeature mqtt:wozipi_bme680:temperature no encontrado
[...y así sucesivamente]
Estos errores aparecen cada pocos segundos (mi WoZiPi envía mensajes MQTT continuamente). En la versión 4.66.9 esto aparentemente se manejaba en silencio — en la versión 4.67.0 parece causar un bucle de CPU.
También notable: ps aux no está disponible dentro del contenedor, pero los errores todos provienen del proceso Node.js (index.js), por lo que sí — es el proceso Gladys Node.js el que causa el pico.
No uso HomeKit, por lo que la actualización de la dependencia HAP probablemente no sea la culpable. Mi suposición sería un cambio en el manejo de rechasos de Promesas no manejadas entre la versión 4.66.9 y la 4.67.0.
Por cierto, vamos a lanzar una mejora en la integración de Nuki en la próxima versión de Gladys para evitar que la integración de Nuki se inicie si no está configurada, ¡así que esto podría ayudarte definitivamente con esto!
Hola,
Confirmo que los registros MQTT adicionales provienen de la integración de Nuki v1, esto debería estar corregido en la v1.0.1 (@mutmut detectó este problema desde el lanzamiento G4.67). La suscripción MQTT al inicio se realizaba en todos los dispositivos existentes, el atributo de búsqueda estaba mal configurado y iba más allá del servicio Nuki, aunque no debería haber tenido consecuencias significativas.
Actualicé de v4.66.8 a v4.71.0 y sigo viendo un uso de CPU de ~60–70%. Después de una profunda depuración, encontré dos problemas separados:
Problema 1: Condición de carrera con mensajes retenidos de MQTT (bucle de reinicio al inicio)
Al iniciar, Mosquitto reproduce inmediatamente todos los mensajes retenidos en gladys/master/# antes de que Gladys termine de cargar su caché de dispositivos. Esto causa una inundación de errores NotFoundError: DeviceFeature mqtt:xxx not found — uno por cada tema retenido, por cada reinicio. El pico de CPU se debe a las promesas no manejadas que abruman el bucle de eventos.
Solución temporal: eliminar todos los mensajes retenidos en gladys/master/# usando mosquitto_pub -r -n. Después de un reinicio, Gladys los vuelve a poblar y funciona correctamente — pero solo hasta el siguiente reinicio.
Esto parece ser un error donde el servicio MQTT se suscribe antes de que el administrador de dispositivos termine de inicializarse.
Problema 2: Escáner de presencia del Administrador LAN llamando a ip neigh show en un bucle cerrado
Incluso con el Administrador LAN configurado como « desactivado » en la interfaz de usuario (y LANMANAGER_PRESENCE_STATUS=disabled confirmado en la base de datos), Gladys sigue generando ip neigh show a través de execve de manera continua. Dado que ip no está instalado en la imagen Docker de Gladys (código de salida 127), cada llamada falla inmediatamente y el bucle se repite.
Lo confirmé con strace -f -e execve en el PID de Gladys.
Solución temporal: inyectar un script ip ficticio que finaliza correctamente reduce ligeramente la sobrecarga, pero el bucle en sí continúa.
Esto parece ser un error donde el Administrador LAN no respeta el estado desactivado en tiempo de ejecución.
Entorno:
Gladys v4.71.0 (actualizado desde v4.66.9)
Docker, network_mode: host
Broker Mosquitto externo (eclipse-mosquitto:2.0)
~30 dispositivos MQTT (en varias Raspberry Pi)
Host: Ubuntu 24.04, 32 GB de RAM
¡Estoy encantado de proporcionar más registros o probar parches si es útil! ¡Gracias!
¡Gracias por el feedback, investigaré ambos problemas
Dicho esto, no creo que se hayan introducido en Gladys v4.67.0, por lo que probablemente no sean la causa raíz del alto uso de CPU que estás viendo.
Como mencionaste que el uso de la CPU es constante (no solo al inicio), tampoco parece un problema de mensajes retenidos.
También mencionaste que tu WoZiPi está enviando mensajes MQTT de manera continua, ¿tienes una idea de la tasa de mensajes (por ejemplo, mensajes por segundo)?
Medí la tasa de mensajes MQTT usando mosquitto_sub -t '#' canalizado a través de pv:
~0.8 mensajes/segundo (291 mensajes en ~6 minutos, todos los temas combinados)
Eso parece estar en el extremo bajo, por lo que no creo que el rendimiento sea el problema. El alto uso de CPU (~60–70%) es constante y no se correlaciona con picos de mensajes.
Para referencia, mi configuración publica estados de relé de tres Raspberry Pis (WoZiPi y AZiPi, SchlaZiPi) además de datos de sensores BME680 y SHT35 — nada particularmente hablador.
