Suite Bug backup Gladys Plus -> Bug global Gladys

Gladys Plus
1

Hello @pierre-gilles,

Bon je suis désolé, je reviens avec de “mauvaises” nouvelles, les problèmes de perf sont toujours présent et toujours avec la même cause : ressources prises par le backup de la base de donnée. Cela ce traduit toujours pas une perte d’accès à Gladys pendant 4/5 minutes toutes les 30 minutes, des backup Gladys Plus très aléatoires, des erreurs sur l’aggrégation permanentes. Cela fait environ 2 mois que ça bug de nouveau(passage du backup au delà de 750Mo ?)

htop

image
image1442×873 101 KB

Taille de la DB sur le pi

image

Taille de la DB sur Gladys Plus + historique des backups

image
image703×682 20.6 KB

Erreur des tâche sur DB bloquée en accès

image
image699×972 86.5 KB

Pour rappel, ma config (avec SSD)

image
image1289×212 32.6 KB

Edit :

Etat des container

image
image1128×92 7.43 KB

Logs avant, pendant et après plantage

image
image1439×871 91.2 KB

image
image1438×875 46.8 KB

image
image1434×844 41.4 KB

image
image1437×856 45.2 KB

image
image1439×877 46.7 KB

image
image1441×408 23.2 KB

Je pensais pourtant que tu avais mis en place des choses pour empêcher de se retrouver sur des problèmes d’accès à la DB pendant le backup. N’y aurait-il pas eu une régression sur ce point ? Ou je me trompe ?

Suite à votre dernière vidéo cela m’a motiver à reprendre la partie prog solaire grâce à node red. J’ai donc de nombreuse données supplémentaires à intégrer (production sur 3 phases + cumul / consommation sur 3 phases et 3 parcs + cumul / différences entre les 2) Ca représente environ 72 features dont 12 valeurs toutes les 30s, 24 valeurs toutes les 1h, 12 valeurs tout les jours, 12 valeurs mensuelles et 12 valeurs annuelles.
Pour le coup cela m’inquiète un peu pour le futur. N’y a-t-il pas moyen de couper le backup. Mon SSD étant lui tout à fait capable de gérer la sauvegarde de ces données, je passerais bien par une sauvegarde en interne si c’est seulement Gladys Plus qui pose problème.
Pour info je suis en pleine campagne, je fonctionne sur 3 réseaux internet (satellite starlink en prio, free 4G en secondaire et free adsl - 512Ko en secours) qui coupe chacun régulièrement. Mais le débit Starlink est excellent (120 méga en moyenne). Est-ce que une coupure internet pendant la sauvegarde peux expliquer cela ?

Merci par avance.

2

J’ai l’impression qu’il backup la DB en permanence … ça doit se faire 1 fois par jour normalement on est d’accord ? Car il y 20 minutes, le fichier dans /var/lib/gladysassistant/backups/ était “gladys-db-backup-2022-3-23-7-38-31.db.gz” et maintenant “gladys-db-backup-2022-3-23-7-53-52.db” soit 2 backups en moins de 15 min…

Je suis en train de récupérer la DB pour voir si il y a des valeurs NaN

Edit : Aucune valeur NaN retrouvée. Juste des valeurs négatives, mais je suppose que ça n’a pas d’impact. Toutefois lors de la recherche par CTRL+F (TablePlus) j’ai une erreur database disk image is malformed … Incidence ??

image
image983×358 43 KB

3

Derniers logs avec erreurs :

image
image1272×1248 102 KB

4

T’as plus de place ou plus de ram dispo

“out of memory”

5

Salut @Terdious ! Ton instance gargantuesque continue de nous donner des challenge !! :smiley: C’est cool, ça va nous permettre de bétonner encore plus le logiciel :slight_smile:

Effectivement, comme le dit le message d’erreur à la fin, les backup échouent pour un soucis de RAM disponible lors de l’upload ! Et donc ils sont re-essayé régulièrement.

Tu as combien de RAM disponible par curiosité ? Est-ce que tu peux regarder un peu ton usage RAM pendant un backup ?

Ce qu’il est possible (à vérifier je ne me rappelle plus), c’est que le backup soient chargé entièrement en RAM lors de l’upload, ce qui poserait problème vu que ton backup fait 800Mo, si ta RAM est de 1Go je comprend que ça coince ! Si c’est ça, la solution serait de passer à un upload en chunk pour éviter d’utiliser autant de RAM. (c’est largement possible que ce soit ça, il faut que je check comment ça marche côté code Gladys)

6

Merci @VonOx et @pierre-gilles pour vos retour.
Ça m’étonnerais fort bien que ce soit la RAM qui pose problème. C’est pour cette raison que sur le dernier imp écran je vous ai mis la barre du bas : 350 Mo used sur 8Go ^^

Le max que j’ai pu observer c’est 8xx Mo. Par contre pendant le backup je suis à 100% de la CPU ( avec des pointes à 112% … :thinking:) et ne lâche jamais la main.

Après un redémarrage, le backup se lance et cette fois laisse la main à l’agrégation régulièrement. Mais 30 minutes après c’est rebelotte ^^

7

Tu es certain pour la RAM ? L’erreur la est plutôt claire, c’est une erreur out of memory ! (350mo c’est pas l’usage après que le process à crash ?)

Sinon il y a la taille de la heap size JavaScript, mais sur Node 14 c’est 4Go donc je pense pas que ce soit ça…

8

Oui vraiment sûr pour la RAM

Screenshot_20220323-213319_Chrome
Screenshot_20220323-213319_Chrome1049×168 88.1 KB

Pour les 350Mo oui en effet c’était après le crash. Mais de mon côté visuellement jamais vu au-dessus de 1Go c’est certain. Je peux refaire des sessions de visu mais pas évident de chopper les pointes je suppose… Et comment serait-il possible que ca dépasse les 8Go ??:sweat_smile:

9

Oui c’est sûr 8Go impossible

Tu n’as rien sur ta machine qui pourrait kill certains process en cas d’usage RAM trop élevé ? Pas de limite mise sur docker par exemple ?

10

:sweat_smile::sweat_smile:

No sorry !! Apres nos recherches précédentes sur la base de donnée, j’avais tout clean pour le SSD. Donc ce pi n’est utilisé qu’avec les container que tu vois sur mon précédent message, installée avec l’image Gladys officiel. Rien touché depuis.
Mon mosquitto et node red tourne sur mon autre pi avec Gladys Pro et Gladys Netatmo.

Je ne t’aide pas pour le coup … désolé

11

Non mais attend tu as combien de Gladys qui tourne ?
Je ne veux même pas imaginer le nombre de scènes.
Vivement te voir un mardi.

Ça non plus ça n’aide pas. :wink:

1 « J'aime »
12

Je me posais la question (donc je vous la transfère) :
Les backups G+ se font-ils de manière planifiée ou plutôt aléatoirement ?
C’aurait un intérêt ici de les planifier pendant la nuit où Gladys est moins sollicité.e ?

13

Du coup j’imagine que c’est un Pi 4 8Gb ? Tu as installé un système 64 bits dessus ?

Aha on touche le point !!

L’image Gladys officielle était jusque là une image 32 bits, donc tu ne peux pas utiliser les 8Gb de RAM. Au mieux tu peux utiliser 3GB environ.

Mais tu es chanceux :smiley: On vient de travailler avec @VonOx sur une image officielle en 64 bits. Après pour l’instant on est en phase de test, mais j’ai testé personnellement et ça marchait très bien :

1 « J'aime »
14

Dans tous les cas, c’est pas normal que l’upload prenne autant de RAM, de mon côté je vais enquêter sur le sujet (sur mes jours Gladys, demain ou lundi/mardi ) et essayer de mettre en place un upload moins gourmand.

De ton côté, passer à un système 64 bits serait une bonne solution à court terme pour utiliser au mieux toute la RAM de ton système :wink:

1 « J'aime »
15

Aucun soucis !!

Avant ça souhaite tu observer le cas et regarder directement sur ma session ? Si ça peut t’aider à voir exactement le soucis … ^^ Ma porte est ouverte en prise de contrôle à distance ^^

Dans tout les cas, merci !!

16

C’est pas forcément la peine, je peux reproduire chez moi un upload d’une grosse DB :slight_smile: Tu peux mettre à jour ton système !

Actuellement Gladys vérifie toutes les 2h si un backup a bien été fait dans les dernières 24h: si oui, elle ne fait rien, si non, elle lance un backup.

Après jusque-là à part dans le cas de @Terdious, les backups étaient quasi instantanée donc ça posait pas de problème en pleine journée :smiley:

Mais peut-être que ça vaudrait le coup de les mettre la nuit si ces backups deviennent plus lourd pour tout le monde :slight_smile:

17

Pour info j’ai créé une issue Github par rapport aux backups :

@Terdious tiens nous au courant quand tu passes en 64 bits !

18

Salut @pierre-gilles,

Merci pour l’issue @pierre-gilles . En effet le problème vient, en tout ou partie, d’un problème d’utilisation mémoire en cache :
image
7.3Giga utilisés en caache toutes les 30 min … voilà la raison du plantage … mais là c’est plus tenable, je ne peux plus rien faire…

Mmmmmh je n’ai peut-être pas compris ton message précédent …

C’est une version officielle avec les maj ? Ou une version de test ? Désolé pour la demande, mais n’ayant pas d’autres pi (j’en ai bien assez ^^), je ne peux pas me permettre de tout casser comme ça (même si c’est déjà cassé au final ^^). Mon dernier backup Gladys Plus remonte à plus de 10 jours …

Donc pour toi je peux installer la version 64 bits sur le SSD directement ?

19

Je ne vois rien de bizarre dans le screenshot que tu partage, la mémoire « buff/cache » n’est pas de la mémoire utilisée, si une application en a besoin elle sera libérée par le système.

Ici, seulement 228mb de RAM sont utilisés, ce qui est tout à fait normal :slight_smile: Mais j’imagine qu’aucun backup n’est en cours d’upload dans ton screenshot.

Cf: linux - "buff/cache" is very high, how I can free it? - Unix & Linux Stack Exchange

En fait actuellement ton problème survient probablement lors d’un backup, comme tu utilise un système 32 bits, un même process ne peut pas utiliser plus de 3GB de RAM sur les 8GB que tu as pourtant sur ton système. Passer à un système 64 bits te permettra d’utiliser les 8GB de RAM en entier, sur un seul même process.

Comme dit le site de la fondation Raspberry:

Our default operating system image uses a 32-bit LPAE kernel and a 32-bit userland. This allows multiple processes to share all 8GB of memory, subject to the restriction that no single process can use more than 3GB

Source: https://www.raspberrypi.com/news/8gb-raspberry-pi-4-on-sale-now-at-75/

C’est une version officielle, mais encore en phase de test, donc c’est du semi-officiel si tu veux :smiley:

En gros pour l’instant @VonOx a fait le build, moi je l’ai testé en 1h environ, et mes tests sont positifs. En revanche pour l’instant on a pas eu d’autres retours d’autres membres de la communauté en usage plus « réel », donc je te garantie pas que ce soit 100% bug free, on a pas le même historique que sur l’image actuelle en production.

A toi de voir si c’est assez production ready pour toi ou pas.

Fais des backups avant du coup (en stoppant Gladys avant pour que tes fichiers de DB ne soient pas corrompus), vu que tes backups ne fonctionnent plus à cause de ce manque de RAM :slight_smile:

20

En effet autant pour moi !!^^

Lol, si j’avais bien un backup en cours depuis 8h30 ^^

:slight_smile: Oui ça j’avais compris ^^, je connais le sujet :wink: Je ne comprenais pas du fait du message cité en-dessous ^^

Oki c’est plus clair pour moi, merci pour ton retour.

Du coup je me suis lancé, j’avais un SSD en rab’ ^^ C’est en cours de réinstallation ^^
image

Je vous fais un retour par la suite.