Merci, Ca parait évident après coup. Je n’avais compris sur le coup qu’il fallait choisir le plugin MONITORING comme équipement pour avoir au accès au informations de la SmartBox 
J’ai choisi comme déclencheur [PROGRAMMEE] 03h00 du matin tout les jours
Voici le résultat de mes essais.
Après plus de deux jours de fonctionnement, ce matin le swap était toujours à 100%
Mais ce soir il était descendu à 86% !
Suivant les conseils j’ai donc redémaré un à un les daemon des différents plugins.
Il n’y a pas de daemon sur mes autres plugin, je ne sais donc pas comment/si on peut les redémarrer.
J’ai donc identifié trois plugins officiels et en versions stable, qui font diminuer le swap.
Mais je n’ai pas trouvé le moyen de récupérer 100% de swap, sans redémarrer la box, ce que je n’ai pas fait.
Même si j’avoue que je n’y connais pas grand chose, mon intuition me fait penser que le problème ne se solutionnera pas en intervenant (uniquement) au niveau des plugins.
Pour le moment je me garde bien de redémarrer la box, j’attend de voir comment cela va continuer à évoluer.
Hello,
J’essaie
Je suis passé de 74 à 92%
En revanche je laisse les démons redémarrer seul
Merci pour l’info
Passer de 92 à 80 % sur un swap de 512 mo n’est à mon sens absolument pas significatif pour établir une quelconque conclusion.
Attendez d’être à 20 % pour relancer les démons 1 par 1 et voir les effets… Et laissez votre système se stabiliser
Rappel : utilisation du swap est normale dans un système Linux
Bonsoir,
Je pense que ta condition « Si » devrait plutot être : Swap Libre plutot que Mémoire Disponible.
Bonjour,
Je peux comprendre que le but du swap est d’être utilisé mais alors pourquoi pendant deux jours le swap reste à 100% et ensuite, en quelques heures il descend à 81% et impossible de le refaire monter à 100%, même en relançant tous les daemons ?
Aussi attendre que le swap soit plus bas pour relancer les daemon n’est jamais qu’une « rustine » pour palier à un problème qui ne semble pas encore identifié.
Cordialement
Philippe
Parceque ton system vit, tu as peut-être lancer une page de config, un scenario ou des crons qui ne tournent que toutes les nuits, …, tu t’es connecté en SSH et tu as lancé des commandes, tu as fait des MAJ, le systeme a eu besoin de créer des process apache à la volée, … Les raisons peuvent être multiples.
Sur un system linux, l’utilisation de la mémoire ne fait qu’augmenter (sauf actions particulières), car le systeme ne décharge des choses de la mémoire que si il n’y a plus de place. Autremenent, tant qu’il peut stocker des choses en mémoire, il les garde car c’est plus rapide à utiliser que d’aller les chercher sur disque si demain il y a un nouvel appel de ce qui est en mémoire (pour résumer, en très gros !)
parce que tu n’as aucune certitude que ce qui est en swap est lié à des process jeedom. Dans ce cas, regarde aussi si la mémoire RAM evolue lorsque tu killes des process
relis ce que j’ai écrit, ce n’est pas ce que je dis :
10% de diminution du swap sur un swap de 512Mo, ca ne fait que 50Mo, ce qui est juste petit pour le moindre process aujourd’hui. C’est pour ca que je dis que ce n’est pas significatif, donc des variations d’utilisation de la ram ou du swap de 50Mo ne suffisent pas pour faire une analyse
Pour info, un process apache utilise plus de 200Mo de mémoire (dont une partie est partagée avec les autres process
Loin de moi l’idée de dire que c’est satisfaisant de killer des process (ce que tu appelles rustine), je dis juste que pour trouver la cause, il faut aller plus bas en usage du swap et KILLER LES PROCESS 1 PAR 1 pour trouver celui qui pose pb
et je le redis :
Avoir un swap à 0 n’est pas un objectif sous linux, C’EST NORMAL, et vouloir purger des process du swap ou de la mémoire alors qu’il n’y a pas de pbs constatés engendra des pbs qui n’existent pas normalement.
En l’occurrence, vos copies de la page santé ne montrent aucun pb, mémoire non saturée et swap non saturé et aucune alerte mémoire insuffisante
Si malgré tout vous voulez avoir un swap à 0 (ce qui est un erreur, je le redis !)
sudo swapoff -a
sudo swapon -a
Norbert
Suis d’accord sur tout.
Mais ceci étant dit, le problème existe.
Aucun problème depuis 5 ans, je suis passé sur un rasp 4 4Go sous Debian 11 et même symptôme j’ai le swap qui grossit inexorablement jusqu’à épuisement de l’os. Un reboot et ça repart. Après recherches, je ne suis pas le seul, et le déclencheur est commun.
Pour l’instant, j’ai:
Ça a ralenti le phénomène, mais ne l’a pas supprimé. J’hésite à upgrader python en me disant que de passer de la version 3.9.2 à 3.9.19 (comme évoqué par bcp sur le forum) ne devrait pas être très risqué (c’est pas une évolution majeure!). QQun a un retour d’expérience sur la manip ?
Oui, il est connu et a fait l’objet de très nombreux posts sur des plugins autour de python
Mais là, dans ce post, on ne parle nullement d’épuisement de l’OS et de plantages
Norbert
Je confirme que mon objectif n’est pas de minimiser l’utilisation du swap mais simplement d’avoir un système robuste.
Si j’ai ouvert ce post, c’est parce que depuis quelques semaines, après un certain temps, des plugins se mettent à ne plus fonctionner correctement, j’ai des erreurs « mémoire suffisante » et j’avais pris l’habitude de devoir redémarrer la box régulièrement pour qu’elle se remette à fonctionner correctement.
Je pourrais donc forcer un redémarrage systématique de la box, mais de l’avis de plusieurs, ce n’est pas une solution propre, et je peux le comprendre.
Aussi, je n’ai pas assez de connaissances en informatique pour dire ce qu’il faudrait ou ne faudrait pas faire. Quand je parle de rustine, loin de moi l’idée de critiquer les solutions avancées, cela peut dépanner momentanément mais cela ne me semble pas une solution pérenne.
Je comprends également que cela ne sera probablement pas facile aux développeurs de mettre le doigt sur le(s) problème(s) qui force à redémarrer périodiquement les plugins ou la box pour que cela reste fonctionnel.
Si je peux contribuer à aider, après 4 jours voici mes constatations:
Après 1 jour : swap = 100%
Après 2 jours : swap = 86%
Après 3 jours : swap = 81%
Après 4 jours : swap = 64%
Conclusion : même en redémarrant tous les daemons des plugins le swap disponible continue de diminuer, un moment donné il sera nécessaire de redémarrer la box complètement
Il faut aussi regarder l’impact sur la RAM des redémarrages de démons
Liste tous les plugins que tu as
Norbert
J’ai le même symptôme, le swap fond doucement mais surement :
Un redémarrage de la box est prévu dans mon scénario si pas assez de swap récupéré après redémarrage des démons…
Bonsoir,
Pourriez-vous SVP poster le résultat de cette commande ?
sudo systemctl status systemd-journald
Bonsoir,
Et moi aussi après 2 jours à donf , j’entame l’inexorable descente qui aboutira à un redémarrage de la Smart dans 1 jour ou deux
* systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: active (running) since Sun 2024-08-25 21:05:16 CEST; 2 months 23 days ago
TriggeredBy: * systemd-journald-dev-log.socket
* systemd-journald-audit.socket
* systemd-journald.socket
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 1886 (systemd-journal)
Status: "Processing requests..."
Tasks: 1 (limit: 1890)
Memory: 60.4M
CPU: 1min 36.633s
CGroup: /system.slice/systemd-journald.service
`-1886 /lib/systemd/systemd-journald
Aug 25 21:05:16 JeedomSmart systemd-journald[1886]: Journal started
Aug 25 21:05:16 JeedomSmart systemd-journald[1886]: Runtime Journal (/run/log/journal/b12e4a1b909f4d96b4735e38f715aef6) is 2.3M, max 18.5M, 16.2M free.
Aug 25 21:05:16 JeedomSmart systemd-journald[1886]: Time spent on flushing to /var/log/journal/b12e4a1b909f4d96b4735e38f715aef6 is 15.361ms for 395 entries.
Aug 25 21:05:16 JeedomSmart systemd-journald[1886]: System Journal (/var/log/journal/b12e4a1b909f4d96b4735e38f715aef6) is 1.0G, max 1.3G, 347.1M free.
Warning: journal has been rotated since unit was started, output may be incomplete.
Si ça peut aider …
Merci
Tout va bien du coté de systemd-journald.
systemd-journald 
c’est déjà un beau début
Comme je suis paresseux, je me contente jusqu’à présent de redémarrer les daemon et la box manuellement.
Sauf qu’en redémarrant le daemon Alexa API qui fonctionnait très bien: bardaf, il a plus voulu redémarrer et j’ai du pour la nième foi regénérer le cookie. Sachant que le premier cookie avait fonctionné pratiquement deux ans 
hello,
Avec une chute de Swap qui semble se stabiliser ,
combien de temps ? ça ; je verrai bien
Hier a midi le swap a commencé a descendre pour se stabiliser ce matin vers 3h
Si je me reprends une chute aussi brutale , la box devra être redémarrée
Comment feriez-vous pour connaitre ce qu’il se passe ?
Merci
