Pb mémoire Atlas depuis migration 4.4

Bonjour

J’ai une Atlas. J’ai suivi la procédure de migration vers 4.4 et nouvelle version de Debian (11) sans encombres. Depuis je constate plusieurs pb:

  1. La mémoire libre ne fait que baisser dans le temps
  2. Le SWAP tend vers et fini à 0 avec le temps (qq jours)
  3. La charge CPU augmente avec le temps, monte à 1 et + avec le temps au lieu de 0.4-0.5 constant avant la migration

Un redémarrage de certains plugin ou de la box libère de la mémoire, mais pour un temps seulement. Le pb reste le même.
J’ai lu sur ce forum que celà serait lié à Debian et/ou Python mais je n’ai pas trouvé de solution officielle ou claire pour une Atlas.

Que va-t-il se passer si la mémoire arrive à 0 ?
Y a-t-il une solution ?
Je ne peux pas ouvrir de ticket support car j’ai le plugin Zoé (ZE) qui est « interdit ». D’ou ce post. Ci-joint 2 captures.

Un grand merci
Manu


Bonjour
As tu des plugin en python (rfxcom ou enocean ou blea par exemple) ? Y’a un soucis en debian 11 et python qui fait ça.

Bonsoir.

Je suis preneur, même en privé, pour avoir la démarche pour modifier la valeur du swapiness sur la Jeedom Atlas.

En effet, sur cette box la valeur du swapiness est définie à 100, alors que sur la Luna cette même valeur est définie à 10. Certe, l’Atlas a 4 go de mémoire RAM, mais voilà, certains plugin depuis Debian 11 créer le problème que tu connais. Il y a pour moi une incohérence de paramétrage entre ces 2 box.

Constaté dans ce fil et sur d’autres fils, la box swap alors que la mémoire diminue. C’est la valeur de 100 qui est en partie responsable de cette surconsommation de Swap, car si l’on en croit la littérature sur ce sujet, plus le swapiness est proche de 0 moins la mémoire swap est sollicité lors des pics de consommation de mémoire RAM, une valeur de 100 indique que le swap est utilisé plus rapidement, ce qui va user prématurément nos stockages.

Pour le plugin RFXCOM, on est beaucoup à avoir le problème, je pense que Jeedom est maintenant bien au courant.

Pour Blea, nous avons récemment eu un mot d’un membre de Jeedom qui nous a clairement signalé que Jeedom (…) ne constatait pas le problème suite au passage à Debian 11 ! (alors que cela est constaté par les utilisateurs et même sur le github de la librairie bluepy responsable du problème).
=> Là, j’avoue, je ne comprends pas l’attitude de Ludovic sur ce dénie du problème. D’autant, que l’on m’a signalé qu’un projet était prêt pour remplacer ce plugin (j’ai l’information depuis septembre 2023).

Loïc, rien.contre toi, bien au contraire, tu es le plus fidèle ici pour nous. Si simplement tu pouvais faire passer ce message.

Mais je reste demandeur pour définir le swapiness de l’Atlas à 10.

Il me vient une idée, cela serait bien d’avoir quelques membres qui seraient des portes paroles entre les utilisateurs et Jeedom pour pouvoir discuter de ce genre de problème que nous constatons ici par exemple, pour en parler avec l’équipe.

1 « J'aime »

Bonjour,

sysctl -w vm.swappiness=10

Valeur dans /proc/sys/vm/swappiness

Pour être persistant, modifier /etc/sysctl.conf

akenad :slight_smile:

2 « J'aime »

Bonjour
J’ai ces 3 là oui.
Et d’autres dont JeeZigbee, Netatmo, Ajax…
Si le bug est connu va-t-il y avoir une mise à jour? Ou dois-je faire qq chose?
Merci
Manu

Le soucis c’est pas le plugin mais un bug de python sur débina 11 on cherche comment faire mais pas de solution simple pour le moment

Pour le swap je remonterais a jeedom le soucis mais je peux rien faire de plus et j’ai pas envie que mon rôle chez je d’OM soit ça mon truc c’est le code rien d’autre.

Pour le porte parole vers jeedom je crois y’a des modo sur le slack mais aucune idée de comment ils sont choisi.

1 « J'aime »

Bonjour
Non que les plugin python ceux la ne sont pas affecté

Stp akenad, est-ce que tu pourrais expliquer plus en détail la procedure pour les non initié en informatique (comme moi). Merci beaucoup.

ssh root

nano /etc/sysctl.conf

vm.swappiness=10

akenad :slight_smile:

1 « J'aime »

Quesiton bête, on ne peut pas avoir une version Atlas officielle sous Debian 10 ou 12 ?
Si non, je fais quoi ? Je laisse la box comme ça sans mémoire ce n’est pas gênant ?
Merci

Bonjour
Pour la version de debian je peux pas te dire je m’occupe pas des os des boxe

Pour le soucis mémoire ont travails dessus mais ça va prendre beaucoup de temps le soucis semble venir d’une live tierce mais sans certitude

Pour la box si elle plante pas alors rien à faire. Pour rappels Linux utilise toute la mémoire disponible c’est normal tu l’as payé autant s’en servir

Bonjour @manu747

Je suis pratiquement dans le même cas que toi excepté que je ne suis pas sur une atlas mais ma mémoire se sature très vite et ma boxe se plante en dessous de 25%

Alors comme j’ai tournée en rond pendant des mois sur tous les forums et passé un temps dingue à chercher le pourquoi du comment dans ma boxe et qu’au final m’apercevoir qu’il n’y a pas de solution a ce jour, que ta boxe soit officielle ou pas !!! Qu’il va falloir attendre qu’un informaticien trouve ou est ce put… de bug qui pollue tout le monde, tu trouveras ci dessous ma bidouille à la portée de tous pour redonner cycliquement un peu de mémoire afin d’attendre la solution officielle.

A ta dispo si besoin

JM

Bonjour

Le problème est complexe, je me trouve dans un cas similaire, je travaille depuis 15 jours sur ce problème. Jeedom est en VM sur Proxmox. La mémoire disponible diminue de jour en jour sur Proxmox et sur Jeedom. Sur ce que j’ai pu observer c’est que la mémoire tampon occupée se stabilise au bout de 2 à 3 jours. La mémoire cache occupée augmente régulièrement. Je redémarre les plugins utilisant Python 1 fois par jour mais la mémoire cache augmente toujours. Pour le journal de systemd j’ai dimensionné son occupation max à 1 Go sur le disque pour Proxmox et Jeedom à 1Go en mode « persistent » c’est à dire écriture sur le disque pas d’utilisation de la RAM. Ce qui est difficile à appréhender c’est que cela prend plusieurs jours pour vérifier que l’occupation de la mémoire se stabilise, une semaine au moins. J’ai observé que de relancer les plugins utilisant Python, la mémoire libérée est marginale pour moi. Je continue mes recherches, j’envisage d’utiliser un utilitaire comme Netdata pour analyser cette mémoire, mais c’est un logiciel sur lequel il faut se former.

Cordialement.

Bonjour,
Pour info une beta du plugin rfxcom vient d’etre pousser, tout a été réécris normalement il ne devrait plus avoir de soucis mémoire avec cette version (attention c’est de la beta !!!)

4 « J'aime »

Bonjour.

Je teste cette version depuis plusieurs jours et le constat est édifiant.

La consommation de la mémoire RAM est stable depuis la modification du plugin.

Plus de consommation de Swap, plus de chute de mémoire sans fin (il faut relativiser, il me fallait 28 jours pour être dans le rouge, la consommation de la mémoire est proportionnellement rapide avec le nombre de périphériques gérés). La relance du daemon RFXCOM était nécessaire pour récupérer cette mémoire. Là, c’est parfaitement stable.

Installation des dépendances et c’est tout. Le plugin reste fonctionnel de la même façon. Prises et sondes fonctionnent toujours aussi bien.

Bravo !

2 « J'aime »

Merci à mips surtout à voir si c’est bien stable dans le temps et si c’est le cas on passera en stable.

Merci pour le retour

2 « J'aime »

Ca serait bien d’avoir un retour de quelqu’un sur smart (pour debian10 malheureusement), en principe ca tourne sous python3.7 mais je n’ai pas le matos pour tester et perso de manière générale je ne teste plus à fond sur debian10 qui est obsolète mais pour les smart c’est nécessaire

vu le nombre d’utilisation du plugin il y a surement quelqu’un avec une smart qui l’utilise

1 « J'aime »

Bonjour
Je viens de passer sur cette beta. A voir à l’usage.
Merci :+1:

Bonsoir

Je viens de l’installer aussi sur Odroid N2 Debian 11 Python 3.9.2
Tout semble fonctionner. Je vais mettre en pause mon scenario de récupération mémoire et vous ferais un état d’ici quelque jours.

Merci Loic :+1:

Bonjour,

Oui, un gros merci à Mips pour cela.

Voici le graphique de la mémoire libre (base 4 Go), lors de l’usage du Plugin RFXcom depuis le passage sous Debian 11.

4 « J'aime »