Tengo los 2 cálculos de consumo que no avanzaban nada rápido y al mirar las curvas de la CPU (4vCPU), no superaban el 10%.
¿Estamos en un solo hilo para los cálculos o me equivoco completamente?
El bloqueo fue a las 22:17 en el gráfico, el blanco corresponde a información no recuperada, Gladys funcionaba muy bien.
En cuanto al disco, tengo subidas/bajadas y desde el bloqueo me he quedado muy alto.
Después de la investigación, es mi script en proxmox el que detecta que la RAM está al máximo (5.9GB/6GB) durante la migración y reinicia entonces el docker Gladys.
Voy a desactivar eso.
Pero, ¿cuánta RAM se necesita para migrar un dispositivo sin migrar su historial?
Me parece que consume mucha memoria.
No tengo muchos (escena/panel) donde uso el anemómetro, por ejemplo (ese era el que intentaba migrar.
Mi duckDB tiene casi 10Go, ¿eso afecta?
En cualquier caso, ayer migraba el dispositivo sin ningún historial y la RAM subía hasta que se bloqueaba (6Go) y luego reinicio manual por OOM.
Hoy he pasado mi LXC de 6 a 8Go de RAM, ejecutar la migración sin historial: ¡muy rápido!
Aïe, efectivamente si tu base de datos es de 10 GB y hay muchos estados para migrar, entonces sí, puede llevar mucho tiempo y mucho RAM.
¿Tienes la posibilidad de asignar temporalmente más RAM solo para la migración?
Sobre la memoria que « no se libera » después: es normal y no es una fuga. DuckDB mantiene sus páginas en caché hasta su límite de memoria y el sistema no la devuelve inmediatamente. Se reutiliza por Gladys y se libera bajo presión.
Y te recomiendo desactivar el reinicio automático por umbral de RAM durante este tipo de operación: reiniciar Gladys en medio de una migración deja el trabajo a medio hacer (es reproducible, pero mejor evitarlo).
Ya hecho, pero tendré que pasar a 10 o 12 GB porque tengo una migración en curso desde hace más de 1 hora y los 8 GB están llenos y Gladys se bloquea, el panel de control ya no se actualiza
Vale, voy a vigilar entonces para ver qué pasa con el tiempo.
Bueno, me voy a reiniciar Gladys de nuevo
¿Alguien ha tenido el mismo problema con una migración?
@mutmut, No hay problema por mi parte con una configuración casi idéntica a la tuya.
He migrado mi termostato Netatmo sin problemas, sin ralentización y ha sido muy rápido. Mi base de datos es de 6 GB
He logrado pasar mi LXC a 12Go en vivo sin reiniciar y la migración de mi estación externa (con todo por migrar) ha tomado 1h26 y un gran ralentizamiento en los cálculos de consumo durante la migración.
Me cambio a la sonda interna con todo por migrar.
En cualquier caso, para los 4 módulos a migrar, uno por uno, llevo más de 24h
El problema principal que veo es que mientras la migración no esté terminada, el cálculo de consumo está en espera, así como todos los que llegan después.
Sería necesario reducir la prioridad de la migración para permitir que los cálculos de consumo se realicen y también permitiría tener siempre el control sobre los dashboards.
Por ejemplo, el cálculo de consumo acaba de iniciarse, por lo que hay 2 tareas con la migración, y esto ralentiza mucho mi Gladys.
¡Gracias, estos números son muy útiles y tu análisis es correcto!
Lo que es caro no es el historial del dispositivo que migras, sino el tamaño total de tu base de datos: cada funcionalidad se mueve mediante una consulta que recorre y reescribe fragmentos distribuidos en todo el archivo de 10 GB. Una estación externa = 4 a 6 funcionalidades = tantas pasadas completas, de ahí tu 1h26. También es por eso que @Will_71 no vio nada: un termostato tiene tres veces menos funcionalidades en una base de datos más pequeña. Y te lo advierto ahora mismo: la sonda interna será la más larga de las cuatro, es el módulo con más funcionalidades.
Sobre tu sugerencia de bajar la prioridad de la migración: tienes razón en el principio, pero no hay prioridad que ajustar: el desplazamiento es hoy una sola gran consulta SQL, y mientras esta se ejecuta, nada puede intercalarse. La buena corrección es dividirla en porciones, como ya hace la purga de estados: la memoria sigue limitada, y Gladys recupera el control entre cada porción para los cálculos de consumo y los dashboards. Es lo que voy a hacer, con una verdadera progresión (hoy te quedas bloqueado al 5% durante toda la operación, lo que no ayuda a nadie).
El hecho de que hayas tenido que subir a 12 GB no es normal: no es caché, es memoria de transacción no limitada. Después del correctivo, debería funcionar sin necesidad de añadir nada.
@spenceur tu caso de eliminación probablemente tiene la misma raíz y será revisado al mismo tiempo.
Gracias por tus medidas, han permitido encontrar el problema y está corregido.
La causa. El desplazamiento del historial lanzaba una consulta por funcionalidad, y cada una de ellas escaneaba toda tu base de datos. El costo real no es proporcional al historial del dispositivo que migras, sino al producto (número de funcionalidades × tamaño de la base de datos). Una estación meteorológica tiene 5 o 6 funcionalidades, por lo que 5 o 6 pasadas completas en tus 10 GB: ahí tienes tu 1h26. También es por eso que Will_71 no vio nada con su termostato, menos funcionalidades en una base de datos más pequeña. Y tu comentario sobre la prioridad era correcto: la migración monopolizaba la conexión de escritura de DuckDB desde el principio hasta el final, nada podía interponerse.
Lo que se ha hecho. El historial ahora se desplaza por lotes, todas las funcionalidades tratadas en la misma consulta. Gladys libera la mano entre cada lote, con una pausa voluntaria de la duración del lote, para que los cálculos de consumo y los dashboards sigan funcionando. El progreso es real, con un contador de estados desplazados en directo, se acabó el 5 % estático. La eliminación de dispositivos se ha corregido de paso, es el mismo mecanismo (debería responder a spenceur).
Las medidas, en una base de prueba de 2,9 GB y 176 millones de estados, para un dispositivo de 6 funcionalidades:
• duración: 347 s antes, 18,6 s después
• tamaño del archivo DuckDB: duplicaba durante la operación (2,9 GB que pasaban a 5,8 GB), ahora aumenta un 6 %
En una base de datos 5 veces más pequeña, la ganancia era solo de un factor 4,5, frente a 18 aquí: cuanto más grande es la base de datos, mayor es la ganancia, por lo que en tus 10 GB debería ser al menos igual de bueno. Cuenta más bien con un factor 9 en la práctica, la pausa voluntaria cuesta aproximadamente la mitad del tiempo, es el precio para que Gladys siga siendo utilizable.
Mis reservas, para ser honesto contigo:
No he logrado reproducir tu explosión de RAM a 8 GB en mi base de prueba, la ganancia de memoria medida es modesta. Lo que he reproducido muy claramente es el doble del archivo en el disco, y creo que es eso tu verdadera causa: en un LXC, la caché de disco cuenta en la RAM vista por tu script Proxmox, por lo que escribir 3 GB más llena la memoria tal como él la mide. Esto coincide exactamente con tus curvas de disco. Pero hasta que no lo hayas vuelto a probar en tu casa, sigue siendo una hipótesis.
et bien non, « solo » 44mn07s pero con 12Go de RAM el tiempo que pase.
¡Genial! porque no aportaba información adicional.
Lo he tenido efectivamente porque mi LXC tenía 20Go de disco y tuve que pasarlo rápidamente a 30Go para no estar bloqueado por el espacio utilizado por la base de datos.
En cuanto a la caché, ahora que lo mencionas, es de 1Go en mi LXC y cada vez que la RAM explotaba, la caché estaba completamente llena. No sé si era antes o después, sin embargo.
Cosa extraña cuando pasé a 12Go temporalmente, la RAM subió casi al máximo y una vez terminadas todas las tareas bajó a 7-7,2Go sin bajar más o subir. La caché estaba siempre llena, así que me permití un pequeño reinicio y volví a 8Go.
Actualmente estoy alrededor de 5Go de RAM de los 8Go asignados, el intercambio está casi vacío.
Voy a intentar volver a probar la migración con tu próximo parche en una copia de seguridad que tengo en una instancia de prueba, para ver la diferencia y te mantendré informado aquí.
En cualquier caso, ¡gracias por tu investigación y resolución!
Para información, las pruebas concluyentes en una zimaboard y docker con 7Go de ram para Gladys y poco espacio en disco disponible (1.5Go de libre para una duckDB de 5.5Go):
La ram ha aumentado un poco, pero sin llegar al límite.
¡Excelente optimización, bravo @pierre-gilles
En mi proxmox con LXC (6go de ram y una DB de 5.5Go): aproximadamente 500-700Mo de disco utilizado durante la migración, y un DUCKDB_MEMORY_LIMIT=2000MB en mi docker compose.
