Je confirme je suis a 280Mo en croisière
1 « J'aime »
13 heures apres gladys est a 742Mo
Moins de 48 h : 1Go
48h : 6Go81
Je pense bien quil y ai un soucis
1 « J'aime »
J’ai pas le même comportement, 280MB 
La différence notable que j’ai faite, la mise à jour de mes packages ( docker a été mis à jour )
Tu as des caméra ? Si oui quel est le taux de rafraîchissement ?
Jai 1 milion de ligne ffmpeg a 26.5Mo perso dans les process avec 1 seul caméra qui sactualise toutes les 10 secondes.
Est ce normal que les process ffmpeg s’accumule et ne se kill pas ?
ouai j’ai 2 cams ( refresh 60s )
Pas sur que ça soit normal autant de flux.
J’ai aussi l’impression que ton syno t’affiche également la mémoire cache ( si tu veux installer htop dans ton conteneur apk add htop )
De mon côté je suis à 300Mb réél et 2.34Gb avec le cache.
EDIT: J’ai attendu un peu, je vois le process ffmpeg qui spawn ( pour le refresh ) puis dispatait une fois l’opération terminé, donc c’est pas normal chez toi. Je regarderai si mon conteneur monte en mémoire.
1 « J'aime »
Merci de ton aide
Voici mon htop idem pas mal de ligne ffmpeg
jai rien dit jai bien 6 Go en physiques 
Ouai la ram est vraiment bouffée.
Faudrait que tu fasse le test d’augmenter le temps de refresh et de restart ton conteneur.
Cest a dire ? 
Je pense que @VonOx veut dire de changer la fréquence de refresh de la caméra (pour passer de 10sec à 1min par exemple).
Dacc je fais
Je tien au courant d’ici deux jours environ
Actuellement 206Mo
Exact je parlais des caméras sorry 
Np merci de ton temps ^^’
Effectivement il y a l’air d’avoir un souci, clairement tous ces process ffmpeg qui restent c’est pas normal
Tu as rien dans les logs qui pourraient expliquer pourquoi ffmpeg ne se ferme pas ?
Normalement, à chaque refresh de caméra, un process ffmpeg est lancé puis se coupe une fois qu’il a l’image.
Je regarde des que jai 10 min, merci P-G
@VonOx, @pierre-gilles, Pour info, depuis le changement de refresh de 10s a 1min jai plus 1 milions de process qui tourne.
Je continue a surveiller mais le probleme pourrait venir de la ?
1 « J'aime »
A mon avis non, tu as juste réduis par 6 le problème donc forcément il met plus de temps à arriver mais le problème est sûrement toujours là
Je confirme avoir le même problème (j’en parle ici : RSTP Caméra : bug "envoyer par message").
Un redémarrage du conteneur de Gladys permet temporairement de « fixer » le problème de RAM, mais il y a clairement un soucis.
J’ai remarqué que l’image sur le dashboard est mise à jour dans tous les cas en arrière plan, même lorsqu’il n’est affiché sur aucun périphérique.
→ Il faudrait peut être demander la dernière image en cas de chargement d’un dashboard plutôt que tout le temps en arrière plan ?
L’autre erreur, c’est que le thread ffmpeg ne s’arrête jamais.
Yes il y a clairement un souci, à mon avis:
- soit un bug ffmpeg introduit dans une version récente de ffmpeg
- soir un changement dans l’API de ffmpeg qu’on a pas intégré dans Gladys
- soit un changement dans Node 18 dans la gestion des child process
Il faut enquêter, j’ai pas encore eu le temps de mon côté, preneur d’aide sur le sujet
Edit: Pour info on utilise cette lib dans Gladys:
Après en voyant toutes les issues remontées (295 issues), et le fait que la lib n’est plus trop maintenue, pour ce que ça fait on ferait mieux de juste lancer ffmpeg nous même via un child process Node pour pouvoir le fermer proprement
Ca à la base c’est une feature (et pas un bug)
L’intérêt c’est d’avoir tout le temps une image fraîche en mémoire afin que si tu ouvre le tableau de bord, tu ai directement une image fraîche servi depuis la memoire, et pas de délai à attendre le temps qu’une nouvelle image soit récupérée
1 « J'aime »
Ce qui est en soit une bonne idée, mais l’impact CPU est assez fort. Je n’imagine pas si on connecte 5 caméras ou plus dans Gladys.
Chez moi (mini-pc) je suis passé de 6% en moyenne à 50% voir 70% (Image toutes les 10 secondes).
Pour économiser en perf, Gladys pourrait mettre à jour en arrière plan, mais toutes les minutes tant qu’un dashboard n’est pas chargé ?
Enfin, c’est un détail ici, vu l’autre bug bien plus important !
le problème de perf c’est déjà du background, ffmpeg est executé par le serveur.
C’est le but de ce paramètre « 1 minutes/30 secondes/10 secondes » etc… à la base
Là vous utilisez ce paramètres pour créer un faux semblant de live sur le dashboard, mais bon c’est trop gourmand car c’est pas vraiment fait pour ça ^^
Pour le live sur le tableau de bord, je suis d’accord que c’est une évolution sympa à apporter et à développer proprement
2 « J'aime »