La valeur d’un swap a un instant ‹ t › ne reflete rien.
Cela veut dire qu’a un moment ta RAM etait saturee donc il faudrait identifier le processus qui fait exploser ta RAM. Le systeme ne le vide pas meme s’il n’en a plus besoin.
Tu peux remettre le swap a 0 en faisant un
sudo swapoff -a
sudo swapon -a
Ces commandes fonctionneront si le systeme peut mettre l’ensemble du swap en memoire.
Effectivement ma première méthode de modification revient à 60% après reboot.
Mais en éditant le fichier sysctl.conf dans le répertoire /etc et en ajoutant en fin de fichier la ligne suivante : vm.swappiness=19 et bien ça fonctionne même après reboot 
Ça pourrait être sympa de pouvoir régler cette valeur directement dans jeedom voir même être mise lors de l’installation. Si c’est possible.
Bonjour
C’est le cas sur les smart pour les autre système jeedom n’a pas vocation à gérer l’os (normal car les autres c’est du diy)
Merci, effectivement, ça marche.
Donc si on prend les 2 cas :
Je vois pas pourquoi faire apparaitre cet indicateur sur le DIY, qu’est-ce qu’on en a à faire que le swapiness soit à 60% si elle est jamais utilisée sur les grosses configs ? Comment tenir compte de ce qui est instalé en plus de Jeedom sur le serveur ? Exemple, je suis serveur de fichiers, il n’est pas conseillé donc de mettre un swapiness à 80%
Si les distributions mettent 60% c’est parceque c’est une valeur sure.
Là l’indicateur va servir pour qui ? Les DIY en Raspberry ou équivalent avec peu de mémoire.
Je pense que c’est une info intéressante mais ne pas la mettre en rouge car tout le monde s’affole alors que tout va bien. C’est n’est que mon point de vu 
Salut,
C’est bien ce que dit @lunarok justement !
Et perso (à part pour les raspberry éventuellement) je ne vois pas l’intérêt d’avoir une ligne avec le pourcentage de swapiness car ceux qui n’y connaissent rien vont modifier des consignes au risque de tout casser alors que la config par défaut debian est largement suffisante dans la majorité des cas et ceux qui connaissent sont déjà intervenus au besoin sur le swapiness.
Pour ma part sur un NUC avec 16Go de RAM je ne vais certainement pas passer le swapiness à 20 ! Heureusement que je ne suis pas en V4 car effectivement avoir une ligne rouge pour ça ça me saoulerait…
Sans parler de la multiplication des posts à ce sujet alors que cette nouveauté date d’hier…
Je confirme, ça m’a saoulé.
C’est pour ça que je l’ai passé à 19.
Salut,
oui je ne vois pas l’interet d’afficher en rouge cette info ,
cela risque d’affoler beaucoup d’users pour rien …
je suis l’info et je confirme que je ne veux pas m’afficher en rouge
A propos de la VM Jeedom sur delta, je n’ai aucune idée pour le SWAP, mais pour ce qui est de la RAM, c’est paramétrable. La seule contrainte est qu’il faut laisser 1Go de RAM au système. La barrette d’origine fait 2Go, ce qui ne laisse donc que 1Go max pour la VM. Mais puisque la RAM est amovible, on peut monter à 8Go sans problème, probablement même 16Go.
Merci pour ces précisions… ça voudrait dire que, par défaut sans intervention sur la box, une VM jeedom sur freebox delta n’est pas dans les critères demandés (2Go de RAM + 1Go de SWAP)
Exactement, 1Go maxi pour la VM.
Pour le SWAP, Après vérification, jeedom m’indique que j’ai 1Go (100% dispo).
Je n’ai aucune idée de ce dont il s’agit, mais si je peut informer, c’est avec plaisir… Je prendrais le temps de comprendre ça plus tard.
Pour faire simple le swap est un fichier qui va faire office de RAM au fur et à mesure que celle-ci se remplit.
En y réfléchissant ça ne m’étonnerait pas que cette « nouveauté » de la page santé soit encore en lien avec les freebox delta…
Voilà, tu as passé le swappinness à 19 juste pour faire disparaitre la ligne, mais sais-tu les impacts annexes que ca va avoir ?
Clairement sur un NUC ca sert à rien et en plus ca peut être pénalisant dans certains cas (si tu as une utilisation de gros fichiers par exemple, en copie réseau, transcode …)
Donc info qui fait peur sans raison
Effectivement, tu as raison, je n’en connais pas les impacts.
Mais alors, comprends qu’avoir une ligne en rouge c’est signe d’anomalie relativement « grave ».
Sinon, il n’y aurait pas autant de messages sur ce fil.
Donc, pour te suivre, je vais repasser le swappiness à sa valeur initiale mais, de votre côté, serait-il possible d’avoir une couleur moins anxiogène pour, finalement, ne signaler qu’une info?
Tu avoueras que quand je vois ça sur ma prod qui est un NUC, il est légitime que je me pose des questions.
Et pour le test qui est un RPI3
Donc, en fait, cela ne va jamais bien.
Oui oui tout a fait d’accord que c’est pas normal d’afficher ça en erreur. J’ai pareil sur mon NUC et je trouve pas ça normal d’avoir un truc en rouge alors que c’est normal
Je découvre comme vous, ce choix as été poussé sans annonce. Et si il est en 4.0 c’est qu’il est en ‹ stable › (même si il n’y a la aussi jamais eu d’annonce officielle)
Bonjour
J’ai également été inquiété par cette information sur fond rouge suite à la mise à jour en version 4.0.30… La lecture du forum m’a rassuré
En résumé (et pour avancer 
), cette nouvelle information ou sa mise en forme serait à revoir dans une prochaine version de Jeedom :
