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 !
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.
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 !
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 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 ?
@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.
Merci, ces chiffres sont très utiles, et ton analyse est la bonne.
Ce qui coûte cher n’est pas l’historique de l’appareil que tu migres, c’est la taille totale de ta base : chaque fonctionnalité est déplacée par une requête qui parcourt et réécrit des morceaux répartis dans tout le fichier de 10 Go. Une station externe = 4 à 6 fonctionnalités = autant de passes complètes, d’où ton 1h26. C’est aussi pour ça que @Will_71 n’a rien vu : un thermostat, c’est 3 fois moins de fonctionnalités sur une base plus petite. Et je te préviens tout de suite : la sonde interne sera la plus longue des quatre, c’est le module qui a le plus de fonctionnalités.
Sur ta suggestion de baisser la priorité de la migration : tu as raison sur le principe, mais il n’y a pas de priorité à régler : le déplacement est aujourd’hui une seule grosse requête SQL, et tant qu’elle tourne rien ne peut s’intercaler. La bonne correction, c’est de la découper en tranches, comme le fait déjà la purge d’états : la mémoire reste bornée, et Gladys reprend la main entre chaque tranche pour les calculs de conso et les dashboards. C’est ce que je vais faire, avec au passage une vraie progression (aujourd’hui tu restes bloqué à 5 % pendant toute l’opération, ce qui n’aide personne).
Le fait que tu aies dû monter à 12 Go n’est pas normal : ce n’est pas du cache, c’est de la mémoire de transaction non plafonnée. Après correctif, ça devrait passer sans rien ajouter.
@spenceur ton cas à la suppression a probablement la même racine et sera regardé en même temps.
Merci pour tes mesures, elles ont permis de trouver le problème, et il est corrigé.
La cause. Le déplacement de l’historique lançait une requête par fonctionnalité, et chacune balayait toute ta base. Le coût réel n’est donc pas proportionnel à l’historique de l’appareil que tu migres, mais au produit (nombre de fonctionnalités × taille de la base). Une station météo a 5 ou 6 fonctionnalités, donc 5 ou 6 passes complètes sur tes 10 Go : voilà ton 1h26. C’est aussi pourquoi Will_71 n’a rien vu avec son thermostat, moins de fonctionnalités sur une base plus petite. Et ta remarque sur la priorité était juste : la migration monopolisait la connexion d’écriture DuckDB du début à la fin, rien ne pouvait s’intercaler.
Ce qui a été fait. L’historique est maintenant déplacé par tranches, toutes les fonctionnalités traitées dans la même requête. Gladys rend la main entre chaque tranche, avec une pause volontaire de la durée de la tranche, pour que les calculs de conso et les dashboards continuent de tourner. La progression est réelle, avec un compteur d’états déplacés en direct, fini le 5 % figé. La suppression d’appareil a été corrigée au passage, c’est le même mécanisme (ça devrait répondre à spenceur).
Les mesures, sur une base de test de 2,9 Go et 176 millions d’états, pour un appareil de 6 fonctionnalités :
• durée : 347 s avant, 18,6 s après
• taille du fichier DuckDB : il doublait pendant l’opération (2,9 Go qui passaient à 5,8 Go), il grossit maintenant de 6 %
Sur une base 5 fois plus petite le gain n’était que d’un facteur 4,5, contre 18 ici : plus la base est grosse, plus le gain est important, donc sur tes 10 Go ça devrait être au moins aussi bon. Compte plutôt un facteur 9 en pratique, la pause volontaire coûte environ la moitié du temps, c’est le prix pour que Gladys reste utilisable.
Mes réserves, pour être honnête avec toi :
Je n’ai pas réussi à reproduire ton explosion de RAM à 8 Go sur ma base de test, le gain mémoire mesuré est modeste. Ce que j’ai reproduit très clairement, c’est le doublement du fichier sur le disque, et je pense que c’est ça ta vraie cause : dans un LXC, le cache disque compte dans la RAM vue par ton script Proxmox, donc écrire 3 Go de plus remplit la mémoire telle qu’il la mesure. Ça colle exactement à tes courbes de disque. Mais tant que tu n’as pas retesté chez toi, ça reste une hypothèse.
et bien non, « seulement » 44mn07s mais avec 12Go de RAM le temps que ça passe.
Top ! car ça n’apportait rien comme info complémentaire.
Je l’ai effectivement eu car mon LXC avait 20Go de disque et j’ai dû le passer rapidement à 30Go pour ne plus être bloqué par l’espace utilisé par la base.
Concernant le cache, maintenant que tu en parles, il est de 1go sur mon LXC et à chaque fois que la RAM explosait, le cache était totalement plein. Je ne sais pas si c’était avant ou après par contre.
Chose étrange lorsque je suis passé à 12Go temporairement, la RAM est montée presque à fond et une fois toutes les tâches finies elle est redescendue à 7-7,2Go sans jamais allez plus bas ou plus haut. Le cache était toujours plein donc je me suis permis un petit reboot et repassage à 8Go.
Actuellement je tourne aux alentours 5Go de RAM sur les 8Go alloués, le swap est quasi vide.
Je vais essayer de retester la migration avec ton prochain fix sur un backup que j’ai sur une instance de test, pour voir la différence et je te tiendrai au courant ici.
En tout cas merci pour ton investigation et résolution !
