Bonjour,
j’utilise un script pour déterminer combien de mémoire prend le démon MyModbus, initialement pour détecter une éventuelle fuite de mémoire et finalement juste par curiosité.
L’équipement du plugin script est paramétré pour s’exécuter toutes les minutes et la seule commande est la suivante :
Voici le contenu du script (une seule ligne, rien d’autre) :
ps -eo rss,command | grep mymodbus | grep -v grep | awk '{print $1}'
Le résultat obtenu :
On voit nettement qu’à 2 reprises et durant un certain temps, le script a retourné entre 535 et 544 Ko alors qu’en moyenne, le démon utilise environ 27 Mo.
De mémoire, j’ai redémarré le démon le 26 février parce que je croyais que le démon était planté (mais je n’ai pas regardé la remontée des données).
Je n’ai pas redémarré le démon ni modifié la configuration du plugin ni des équipements. La machine Jeedom est une VM Synology.
Page santé :
J’ai vérifié le pid du démon, c’est le même que celui inscrit dans /tmp/jeedom/mymodbus/daemon.pid et la date de ce fichier est le 26.02.2025. Date à laquelle j’ai redémarré le démon par peur qu’il ne fonctionnait plus.
Comment se fait-il que le script de monitoring puisse retourner une valeur si faible et juste durant de faibles intervalles de temps ?
Pour un démon python est-ce que 27 Mo de mémoire est une valeur cohérente ?
A+
Michel
Quelques hypothèses :
- Même si le PID est resté le même, il est possible que le processus ait été en « sleep » ou « zombie » pendant un moment, avant de reprendre.
- Est-ce que vous avez un job de backup qui tourne sur synology qui passerait la vm en mode « sleep » pour la prise d’une snapshot par exemple (je ne connais pas synology, mais ce mécanisme existe sur proxmox par exemple) ? Ca pourrait peut être expliquer le comportement
Peut être essayer avec la mesure du VSZ dans la commande :
ps -eo vsz,command | grep mymodbus | grep -v grep | awk '{print $1}'
car RSS ne représente pas forcément la mémoire totale utilisée, mais juste celle en RAM au moment où la commande est exécutée (et notamment temporairement swapée ou relâchée par le noyau). Voir ici
Non, rien de ce type.
J’ai essayé avec vsz qui est votre proposition qui me parait la plus plosible, du coup c’est passé à 42,5 Mo. Je vais laisser comme ça quelques jours.
Merci pour votre retour.
Je reviens avec ce sujet.
Après redémarrage du démon, je monitore les mémoires VSZ er RSS. Le phénomène est le même : ça grimpe puis d’un coup c’est réduit.
Il semblerait que ce soit le garbage collector qui intervient tard (plusieurs jours).
Prochaine étape : je vais voir pour modifier le démon en y intégrant des appels au garbage collector (je dois encore définir le critère d’appel) pour voir si le phénomène est le même.
Pour info, la mémoire RSS :
RSS:
- démarrage à 34500 Ko
- Pi à 61 500 Ko
- Retombée à 500 Ko (ça oscille entre 500 et 580 Ko)
et la mémoire VSZ sur la même période :
VSZ:
- démarrage à 43 300 Ko
- Pi à 75 900 Ko
- Retombée à 2 480 Ko
Je ne monitore la mémoire système restante (RAM et swap) que depuis quelques jours et n’ai rien remarqué : ça ne progresse pas comme le démon et la libération subite n’apparait pas dans l’historique. Ce qui me porte à croire que c’est une gestion « normale » de mémoire.
En comparaison, le démon de worxLandoidS a des valeurs VSZ er RSS stables (il me fallait un point de comparaison je ne soupsonne pas de dysfonctionnement, bien au contraire).
L’analyse du code par github copilot n’a révélé aucun erreur majeure.
