Plugin wifilightV2 - Utilisation ram / swap

Plugins Objets connectés
1

Bonjour, tout d’abord bonne année à tous !

Après je tiens à remercier @bernardfr.caron pour le super plugin WifilightV2 qui permet d’intégrer un paquet d’objets. :+1:

Pour ma part j’utilise le plugin pour :

  • 16 prises Sonoff S26
  • 2 multiprises Tuya
  • 7 interrupteurs de volets roulants Tuya
  • 1 interrupteur Sonoff Mini (10 autres en boite prévu d’être prochainement montés sur l’éclairage)
  • très prochainement des rubans LED (j’attends le module wifi)
    Et certainement d’autre à venir.

Par contre, j’ai remarqué que le plugin wifilightV2 utilise de la RAM de manière très variable en quantité. Par moment il utilise par exemple 4,3Go (1,3Go de swap et 3,0Go de ram) (et ce n’est pas le cas maximum que j’ai pu constater !), voir image ci-dessous.

imp%20ssh
imp%20ssh1920×994 480 KB

sant%C3%A9
sant%C3%A91920×931 186 KB

Et puis une heure (ou plus) après plus rien.
Au début je rencontrais des problèmes de lenteur et de tâches non réalisées. J’ai donc passé mon swap de 1Go à 2Go, et le swapiness à 10, comme conseillé. Et au bout de quelques jours le problème est revenu.
J’ai donc augmenté le swap encore (à 10 Go …) Et passé tous les plugins et scénarios en Niveau de log « Aucun »

Sur cette constatation de conso de ressources, j’ai plusieurs points qui m’interrogent :

  • Est-ce normal de consommer jusqu’à 5Go de ram + swap ?
  • Quel serait l’explication de cette variation de consommation de 1 pour 10, car le plugin consomme en général moins de 500Mo.
  • Avec l’ajout de futurs modules, cette valeur ne risque-t-elle pas d’augmenter ?
  • Avez-vous déjà rencontré ce cas et comment l’avez-vous résolu ?

J’ai pas mal cherché de réponses sur les forums sans les trouver d’où mon poste ce jour. Vous m’excuserez (j’espère) si certaines questions vous paraissent bêtes, ça ne fait maintenant que 2 mois que j’ai reçu et installé la bête et avant je ne m’étais pas penché sur la question domotique.

Présentation du matériel : ici
Debug : Debug WifilightV2 - Ju1ien.log (412,6 Ko)
Config WifilightV2 :

plugin
plugin1920×994 189 KB

Vue WifilightV2 :
setup
setup1920×994 234 KB

ID 20 qui correspond à WifilightV2 :
imp%20ID20
imp%20ID201920×994 294 KB

Pour le réglage du swap, globalement j’ai suivi les sujets suivants : ici , ici et d’autres que je n’ai pas enregistrés.

2

As-tu essayé de redémarrer le deamon du plugin quand ça arrive ? Pour voir ce qu’il se passe ?
J’ai eu des pb de fuite mémoire à un moment, et un reboot du deamon 1 fois par jour permettait de revenir à la normale

1 « J'aime »
3

Bon je suis arrivé à 6.9Go d’utilisation (en 3jours, 76h exactement) .

imp%20ssh%202
imp%20ssh%2021920×1080 553 KB

@jplp : Merci pour ton retour, oui en redémarrant le demon le volume utilisé est descendu à 50Mo.
Par contre quand je l’ai redémarré il s’est arrêté. Il faudrait donc que je crée un scénario qui l’arrête, le relance, vérifie, sinon attend 45s le relance, etc. Donc potentiellement des actions non réalisées dans ce laps de temps (bien sur je choisirais une heure où rien ne se passe pour avoir le moins de risque)
Bon rien de compliqué en terme de rédaction du scénario mais ce qui me dérange c’est que ce n’est pas propre (enfin je pense !). Je pensais à peu près doubler le nombre de modules d’ici février. Donc il faudrait dans le futur que je relance le demon toutes les 12h à 24h pour ne pas avoir de problèmes.

Suis-je le seul à avoir ce problème ? comment l’avez-vous résolu ?

Je vais continuer mes tests, je vais retirer les alertes pour voir si ça change quelque chose.

Voici le debug de ce jour :Debug WifilightV2 - Ju1ien (2).log (3,4 Mo)

4

Mon scénario arrête et démarre le demon en moins d’1s
Donc en fonction de la fuite mémoire, 1 ou 2 fois par jour peut suffire. Tu peux aussi te baser sur un seuil défini
Au début j’utilisais un seuil de mémoire dispo.
Sous 20% je reboutais le demon et puis qq temps plus tard le pb a disparu, puis est revenu mais moins « violent ». Donc reboot 1 fois par jour à 2h du mat suffisait …

Et puis depuis le 22/12, je n’ai plus de fuite ??! Comme tu peux voir, c’est aléatoire

5

Bonjour,
J’avais détecté il y a quelques temps une fuite mémoire. D’ailleurs le plugin affiche la mémoire occupée par le demon et utilise gc_collect_cycles() toutes les 60s mais depuis quelques mois, plus de problèmes.
je tourne actuellement à :
Memory used :3870 ko 80 o

→ tu devrais avoir ce message dans les logs du plugin

Solution 1
prendre la beta pour V4 uniquement, j’ai fait pas mal fait le ménage dans le demon.

Solution 2 (palliatif)
utiliser le heartbeat fourni dans la config du plugin

Solution 3 (palliatif que j’utilise pour le plugin Mysensors car déconnexion de l’USB de temps en temps)
Mesurer la taille mémoire et se fixer une taille mémoire max (ce qui est mieux que le heartbeat) et dans un bloc code de scenario
message::add(‹ Scénario ›, ‹ Fuite mémoire WifilightV2 ›);
wifilightV2::deamon_start()
Eventuellement, me donner des stats avec cette dernière méthode

J’ai publié ce message dans le salon des développeurs en juin :

Bonjour,
Je voudrais signaler un bug concernant :
$buf = socket_read($socket, 1024);
socket_read() a une fuite de mémoire de quelques octets à chaque fois qu’elle est appelée.
Quand c’est dans un script, pas de souci, la mémoire est rétablie à la fin.

Par contre si elle est utilisée à l’intérieur d’un démon dans une boucle sans fin ce memory leak fini par croitre dangereusement.

De plus, au début il n’y a pas de fuite, puis au bout de quelques heures, la fuite commence pour, en plus, augmenter.

Au final le système n’a plus de mémoire et il faut relancer le démon pour revenir à la normale (cependant Jeedom semble être équipé de ce qu’il faut car il relance automatiquement le démon).

Si cela peut aider pour ceux qui auraient des pertes de mémoire

Les parties du plugin qui utilisent un socket_read :

  \plugins\wifilightV2\3rdparty\tplink.php
	Line 280:  $out = socket_read($socket, 1024);
  \plugins\wifilightV2\core\class\wifilightV2.class.php (2 hits)
	Line 472:         $stringCom = socket_read($clientsock, 4096);
	Line 570: 	$buf = socket_read($socket, 1024);

les 2 derniers sont utilisés par les périphériques tuya et ewelink dans le demon et sont abondamment utilisés.
le premier est appelé par le demon mais rarement.

Difficile de t’aider mieux que cela à distance.

6

@bernardfr.caron Merci pour ton retour :+1:

Bon, pour la fin de ton message (message dans le salon des développeurs), je t’avoue en avoir saisi à peu près les contours mais je serais incapable de l’exploiter. Je l’évoquerais avec un ami informaticien qui a Jeedom.

Sinon pour les solutions, je voulais m’orienter sur installer la beta (donc solution 1) mais en regardant comment faire, cela semble m’obliger à passer jeedom en beta et le retour sur une version stable est impossible et semble faire crasher jeedom :flushed: (voir ici). L’installation d’un plugin en beta sur un jeedom stable ne semble pas possible non plus. J’abandonne donc cette solution, je n’ai pas encore assez d’expérience pour me lancer à l’aventure à ce niveau là (et puis si jamais ça ne marche plus madame va m’obliger à tout déposer :unamused:)

Je vais donc faire un scénario pour monitorer l’usage de la ram du plugin et redémarrer le demon (juste le temps de trouver comment le faire). Je ferais un retour sur les résultats obtenus.

7

non tu peux faire juste plugin beta par contre il faut la V4 sinon je t’envoie en zip.

8

Je suis en V4. Et je peux bien revenir sur une version stable après ?

9

oui mais la beta est plutôt en release donc passage en stable très bientôt
d’ailleurs ça m’intéresse que tu vérifies que les prises tuya marchent bien

10

Je viens d’installer la beta, j’ai testé les commandes des équipements suivants et n’ai pas relevé de problèmes :

1 multiprise Tuya V1 Smart Plug 4 + usb (MCU/Wifi 1.0.3) : On, Off, Etat, Connecté sur les prises (pas testé sur l’usb car ne fonctionnait pas avec le même ID/Localkey que les prises, vu que je ne m’en sers pas je ne m’étais pas penché sur la raison du problème)
1 volet roulant Tuya V2 curtain 1 Mod 1 (MCU/Wifi 1.0.0) : Up, Down, Stop, EtatC, Connecté
1 volet roulant Tuya V2 curtain 1 Mod 1 (MCU/Wifi 1.0.6) : Up, Down, Stop, EtatC, Connecté
1 interrupteur Sonoff Mini (version 3.3.0) : On, Off, Connecté, Etat
1 prise Sonoff S26 (version 3.3.0) : On, Off, Connecté, Etat, TimerGet

Pour la fuite de mémoire, je regarde si ça améliore la situation sur les prochains jours.

11

je regarde de mon côté aussi

12

@ jplp tu as possibilité de me scanner ou m’envoyer (je ne sais pas si c’est possible) ton scénario ? ça me ferais gagner pas mal de temps, Merci :grin:

13

Scénario le plus simple possible
2 commandes :

Arrêter wifilight2
Démarrer wifilight2

Exécution en moins d’une seconde

Par contre ces 2 commandes tu les obtiens avec le plugin jeelink
Je pense qu’il es possible de le faire sans, avec un code, mais je ne maîtrise pas cette partie.

14

@jplp Merci

15

j’ai donné le code ci-dessus.
pas besoin d’arrêter car le démarrer le fait.
de mon côté pas de fuite mémoire, vérifié depuis hier.

16

@bernardfr.caron j’ai essayé le code mais ça ne fonctionnait pas, je vais regarder plus en détail :grin:
Sinon je viens de regarder, environ 47Mo en RAM utilisée, ça l’air d’être mieux :+1:

17

Je vais intégrer dans le plugin le restart du deamon
je fait fixer la limite à 400 Mo

1 « J'aime »
18

ce ne sera pas si facile. Il faudra attendre un peu

19

Bonsoir @bernardfr.caron ,

Mauvaise nouvelle :disappointed_relieved: j’ai toujours une fuite de mémoire.
Je suis repassé sur la version stable donc le 1.54 du 11/01/2020. En supposant que l’amélioration de la fuite de mémoire avait été intégré dans la dernière version stable ? (mais peut-être que je me trompe ? )
Et vu que je redémarre de temps en temps Jeedom pour faire des tests et autres. je ne m’en étais pas aperçu avant.

20

je n’ai pas de solution pour l’immédiat et toutes les versions en ligne sont les mêmes.
mais je vais proposer un correctif.