Derniers logs avec erreurs :
T’as plus de place ou plus de ram dispo
“out of memory”
Salut @Terdious ! Ton instance gargantuesque continue de nous donner des challenge !! 
C’est cool, ça va nous permettre de bétonner encore plus le logiciel 
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)
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% … 
) 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 ^^
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…
Oui vraiment sûr pour la RAM
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 ??
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 ?
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é
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. 
1 « J'aime »
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 ?
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 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 »
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
1 « J'aime »
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 !!
C’est pas forcément la peine, je peux reproduire chez moi un upload d’une grosse DB 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
Mais peut-être que ça vaudrait le coup de les mettre la nuit si ces backups deviennent plus lourd pour tout le monde
Pour info j’ai créé une issue Github par rapport aux backups :
@Terdious tiens nous au courant quand tu passes en 64 bits !
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 :
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 ?
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 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
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
En effet autant pour moi !!^^
Lol, si j’avais bien un backup en cours depuis 8h30 ^^
Oui ça j’avais compris ^^, je connais le sujet 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 ^^
Je vous fais un retour par la suite.
Essai concluant, un grand merci !!! Tout est reparti nickel !!^^
Détails des essais ici :
Un grand merci à @VonOx pour cette version 64 bits !!^^ 
1 « J'aime »