Mémoire qui baisse progressivement depuis 4.4 ou Debian 11

[Mips]

Ah oui j’utilise copilot mais je n’ai pas pensé à lui demander
Il n’est pas trop tard, suffit de fetch une ancienne version

[TiTidom]

Hello,

Voilà ce que réponds copilot lorsque je lui demande s’il y a des fuites mémoires dans le fichier jeedom.py du démon :

Copilot :

There might be potential for memory leaks in the code due to the repeated creation of threading.Timer and threading.Thread instances without ensuring they are properly cleaned up after execution. Here are a few specific areas to check and improve:

1. Threading Timer in send_changes_async Method:

   • The send_changes_async method creates a new threading.Timer instance each cycle without ensuring the previous timer has completed or been canceled.

2. Threading in send_change_immediate Method:

   • The send_change_immediate method creates a new threading.Thread instance for each change without joining or checking if the previous threads have completed.

3. Socket Connections in jeedom_socket_handler:

   • The handle method in jeedom_socket_handler creates socket connections that might not be cleaned up properly.

To improve, consider managing the lifecycle of threads and timers more carefully, ensuring they are cleaned up when no longer needed.

TiTidom.

[dJuL]

Salut Mips,

Oui oui j’avais bien modifié journald.
Je pense que tu as mal regardé ma courbe, c’est à partir du 22/12 les corrections, soit le dernier bloc à droite si tu regardes l’échelle en bas. C’était justement pour comparer avec avant, et on peut voir que le dernier bloc à droite est beaucoup plus stable :

Et ça se confirme depuis le reboot que j’ai fait le 30/12 pour tout remettre bien à 100%.
Le swap reste à peu près stable également :

C’est une smart donc pas beaucoup de Ram, logique que le swap soit tout de même un peu entamé.

[Mips]

@dJuL

Je pense que tu as mal regardé ma courbe

non du tout, j’avais bien vu

@dJuL

le dernier bloc à droite est beaucoup plus stable

« beaucoup plus stable » n’est pas tout à fait satisfaisant à mes yeux d’où ma réponse

mais je suis d’accord que la différence est flagrante et qu’il n’y a plus d’urgence, le tout est de garder un oeil dessus chaque mois probablement.
mon point était de faire un petit tour vite fait au cas où un candidat serait facilement découvert.

[dJuL]

Oui il faudrait que je regarde en profondeur.
La consommation de swap restante n’est peut être plus liée à python.
J’ai par exemple l’impression que zwaveJs consomme du swap avec le temps.
Il faudrait que je monitore tout les plugins pour voir.
Ce qu’il y a de certain, c’est que j’ai coupé le montoring de rflink2 et broadlink, car la ram utilisée ne bouge plus d’un yota.

[GiDom]

Bonjour, je suis tombé sur ce topic à force en cherchant pourquoi j’avais des pics de charges énormes qui rendaient mon Jeedom inaccessible aléatoirement. J’ai utilisé le fichier jeedom.py pour le remplacer dans le plugin RFXCOM officiel, BLEA officiel, squeezebox officiel aussi mais il faut faire d’autre modif dans un autre fichier Python.
J’ai également faire la modif sur jMQTT, il me semble que le plugin Xiaomi-home consommait aussi pas mal de mémoire mais je l’ai supprimé pour passer sur un docker.
Pour l’instant le swap à l’air de rester à quasi zéro sur 24h.
Depuis le passage à Debian11 (sous VM) je constate aussi des numéros de PID très élevés, ce qui je pense signifie que ces processus sont relancés très / trop fréquemment ? j’ai l’impression que c’est mariadb.
Au bout de moins d’une heure de uptime voilà le numéro de PID :

Je n’avais pas ça en Debian10, c’est depuis Debian11. Est ce que c’est un autre « pb » sous Debian 11 connu ? et ce lié à ce même problème Python ?

[Mips]

@GiDom

utilisé le fichier jeedom.py pour le remplacer dans le plugin RFXCOM

Aucun intérêt car ce plugin n’était pas impacté (plugin fixé par une autre méthode il y a des mois)

@GiDom

des numéros de PID très élevés, ce qui je pense signifie que ces processus sont relancés très / trop fréquemment

Ah… et c’est inspiré par quoi cette pensée?
Et même si c’était le cas, quel lien avec le sujet?

@GiDom

même problème Python

Il n’y avait donc pas de problème avec python, juste un bug.

[GiDom]

Je n’ai pas la prétention de faire des affirmations, juste des suppositions, j’avais oublié un point d’interrogation .

J’ai aussi précisé d’autre modif sur d’autre plugin que j’avais effectué en même temps, donc il y en a au moins un dans le tas qui causait un problème de swap.

Si une autre personne à ces plugins et observe un souci ça pourra être une piste, encore une fois je n’ai aucune prétention d’affirmer quoi que ce soit.

[Mips]

@GiDom

J’ai aussi précisé d’autre modif sur d’autre plugin que j’avais effectué en même temps, donc il y en a au moins un dans le tas qui causait un problème de swap.

je dis pas le contraire, il doit y en avoir encore un paquet d’ailleurs (malheureusement)

---

pour revenir à cette histoire de pid, moi j’en sais rien, je suis pas system engineer, mais c’est la première fois que j’entendais ca
donc je voulais lire un article ou une source qui expliquerait le topo; j’ai toujours cru naïvement que c’était aléatoire.

[Madcow]

@Mips

pour revenir à cette histoire de pid, moi j’en sais rien, je suis pas system engineer, mais c’est la première fois que j’entendais ca
donc je voulais lire un article ou une source qui expliquerait le topo; j’ai toujours cru naïvement que c’était aléatoire.

Salut,

L’attribution est incrémentale. Donc les process avec les pid les plus élevés sont les plus récents.
Sauf qu’une fois le pid max est atteint on repart de 2 (ou 300 c’est pas clair).

Process identifier

https://man7.org/linux/man-pages/man7/pid_namespaces.7.html

proc files
/proc/sys/kernel/ns_last_pid (since Linux 3.3)This file (which is virtualized per PID namespace) displays the last PID that was allocated in this Pid namespace. When the next PID is allocated, the kernel will search for the lowest unallocated PID that is greater than this value, and when this file is subsequently read it will show that PID.
This file is writable by a process that has the CAP_SYS_ADMIN or (since Linux 5.9 CAP_CHECKPOINT_RESTORE capability inside the user namespace that owns the Pid namespace. This makes it possible to determine the Pid that is allocated to the next process that is create inside this PID namespace.

[ngrataloup]

cette histoire de pid est tout à fait normal. Pour rappel, chaque commande lancée à son propre pid.
Imaginons les plugins monitoring qui va faire des requêtes système pour remonter la charge, le CPU, la mémoire, … Imaginons 20 requêtes système pour sortir toutes les infos, toutes les minutes → 1200 pid utilisés par heure, 28800 par jour… Et comme ce nb est toujours croissant, ça peut augmenter très très vite.

Norbert

[dJuL]

Je pense qu’il y a une fuite mémoire également avec le plugin plugin-jeedomconnect
Le serveur web socket est en python.
Je récupère beaucoup de swap en redémarrant le demon.

[dJuL]

Bon je pense que pour ma part, c’est tout bon.
J’avais 3 plugins incriminés (ainsi que la conf de journald qui n’avait pas les bonnes limites) sur ma smart.

Voici le swap des 7 derniers jours :

J’ai jamais eu une courbe aussi lisse

Encore Merci à @Mips pour avoir trouvé et contourné ce soucis de queue.

[Mips]

c’était pas la queue le vrai problème finalement (Consommation mémoire des démons python sous deb11 basés sur le plugin-template), il fallait des milliers de messages pour qu’on voit un impact

mais merci quand même

[dJuL]

Ah oui, je l’avais vu ce message c’est vrai.
Un thread lancé dans un thread lancé dans un thread…
La méthode n’était effectivement pas terrible, même si en théorie le Thread parent devrait pouvoir être libéré si il n’attend pas la réponse et que le thread enfant est lancé sans une quelconque synchronisation… Après je maitrise pas bien python…