Suite au démarrage de la migration d’un appareil Netatmo, après 49mn et seulement 5% d’effectué, Gladys à planté et redémarré semble-t-il 
Logs dispo pour analyse.
J’ai les 2 calculs de conso qui n’avançaient pas vite du tout et en regardant les courbes des CPU (4vCPU), ça ne dépassait pas les 10%.
On est sur du mono-thread pour les calculs ou je lme trompe complètement ?
Le plantage est à 22h17 sur le graphique, le blanc correspond à des infos non récupérée, Gladys fonctionnait très bien.
Côté disque, j’ai des montées/descentes et depuis le plantage je suis resté très haut !
Comment fait-on pour nettoyer tout ça ? un reboot du docker ?
EDIT : ajout de la charge moyenne :
Après investigation, c’est mon script sur proxmox qui voit que la RAM est à fond (5.9GB/6GB) pendant la migration et redémarre alors le docker Gladys.
Je vais désactiver ça.
Par contre il faut combien de RAM pour migrer un appareil sans migrer son historique ?
J’ai l’impression que ça bouffe beaucoup de mémoire.
Tout dépend du volume de scène / tableaux de bord à migrer, mais c’est relativement léger je pense.
Après, migrer l’historique ça doit passer largement sur ta machine je pense
Je n’en ai pas énormément (scène/dashboard) où j’utilise l’anémomètre par exemple (c’est lui que j’essayais de migrer.
Ma duckDB fait presque 10Go, est-ce que ça joue ?
En tout cas hier je migrais l’appareil sans aucun historique et ça faisait monter le RAM jusqu’à plantage (6Go) et ensuite redémarrage manuel car OOM.
Aujourd’hui j’ai passé mon LXC de 6 à 8Go de RAM, lancer la migration sans historique : hyper rapide !
Mais alors ça me prend une RAM de fou et surtout la libération de la RAM ne se fait pas du tout après
J’avoue ne pas comprendre ce qu’il se passe, si quelqu’un a une piste ?
EDIT : config de mon LXC docker → 4vCPU, 8Go RAM, Disk 30Go.
Aïe effectivement si ta base fait 10 Go et qu’il y a beaucoup d’états à migrer, alors oui ça peut prendre pas mal de temps et pas mal de RAM.
Est-ce que tu as une possibilité d’allouer temporairement plus de RAM juste le temps de la migration ?
Sur la mémoire qui « ne se libère pas » après : c’est normal et ce n’est pas une fuite. DuckDB garde ses pages en cache jusqu’à sa limite mémoire et le système ne la rend pas immédiatement. Elle est réutilisée par Gladys et libérée sous pression.
Et je te conseille de désactiver le redémarrage automatique sur seuil RAM pendant ce genre d’opération : redémarrer Gladys au milieu d’une migration laisse le travail à moitié fait (c’est rejouable, mais autant l’éviter).
déjà fait
déjà fait mais il va falloir que je passe à 10 ou 12Go car j’ai une migration en cours depuis plus d’1h et les 8Go sont pleins et Gladys plante, le dashboard ne se rafraichit plus
ok je vais surveiller alors histoire de voir ce qu’il se passe avec le temps.
Bon je m’en vais redémarrer encore une fois Gladys
Quelqu’un a eu le même soucis avec une migration ?
Jai le meme soucis quand je supprime un device.
@mutmut, Pas de souci de mon côté avec une configuration presque identique à la tienne.
J’ai migrer mon thermostat Netatmo sans problème, sans ralentissement et çà été très rapide. Ma base fait 6 Go
J’ai réussi à passer mon LXC à 12Go en live sans rebooter et la migration de ma station externe (avec tout à migrer) a pris 1h26 et gros ralentissement sur les calculs de conso le temps de la migration.
Je bascule sur la sonde interne avec la totale à migrer.
En tout cas pour les 4 modules à migrer, un par un, j’en suis à plus de 24h
Le soucis principal que je vois c’est que tant que la migration n’est pas finie, le calcul de conso est en standby, ainsi que tous ceux qui arrivent après.
Il faudrait diminuer la priorité de la migration pour laisser les calculs de conso se faire et ça permettrait aussi d’avoir toujours la main sur les dashboards.
Pour exemple, le calcul de conso vient de se lancer, donc 2 tâches avec la migration, et ça ralenti énormément ma Gladys.
