J’ai hésité à rouvrir ce post car son activité est un peu vieille.
Je me pose la même question: est-il possible de lancer une action système pour faire un cleanup de la mémoire ?
Je constate sur un RPI3B+ 1G avec Jeedom actuellement en 4.2.15 (mais ce n’est pas spécifique à cette version), que la mémoire disponible diminue progressivement, et à un moment donné, je commence à avoir le plugin MQTT qui sort des alertes de connexion, mais ça continue à marcher. Si je laisse, ça empire, puis certains scenarios commencent aussi à ne plus s’exécuter.
Bref, pour éviter cela je surveille et environ toutes les semaines je redémarre Jeedom pour prévenir.
Note: j’ai 2 autres installations Jeedom (sur un Linux Debian DiY et sur un autre RPI), où je n’ai pas ce pb, mais ils ont beaucoup moins d’équipements et de commandes, ils sont moins sollicités (et le Linux a plus de mémoire que le RPI).
Suite à la dernière mise à jour, je me suis rendu compte que la mémoire disponible revenait à un état satisfaisant en comparaison de son état juste avant maj, ce qui m’a évité un redémarrage. Je suppose donc qu’il y a bien des opérations (faites à l’occasion de la mise à jour) qui permettent de faire ce type de cleanup. J’aimerais bien les connaitre pour éviter de redémarrer.
Vous pouvez montrer la page santé de Jeedom après plusieurs jours d’usage.
Histoire de voir de quelle mémoire vous parlez.
Si vous avez un historique du Swap c’est bien aussi.
Question : avez vous modifié l’usage de la mémoire Swap (swapiness à 10% au lieux de 60%) et la taille de la mémoire Swap, à 1 go à la place des 100mo par défaut ?
Le pricipe de base est: Il est normal que Linux utilise beaucoup de mémoire. car il utilise la mémoire qui n’est pas directement nécessaire au kernel et aux applications comme cache.
Ceci dit, il est possible qu’un programme a une fuite mémoire. Vu les dysfonctionnements de MQTT, c’est probablement le cas. Les bon candidats pour ce genre de choses sont les deamons (mais pas seulement).
Il faudrait tenter de relancer les deamons des plugins l’un après l’autre et regarder aprés chaque redémarrage si quelque chose a changé du côté de l’utilisation mémoire.
Au pire, ça montrera que le problème est ailleurs. Au mieux, tu auras identifié un problème sur un plugin et pouras en informer le développeur.
On voit bien le redémarrage hebdo, et le dernier coup la mise à jour qui a aussi récupéré de la mémoire (avant que je fasse un redémarrage hebdo).
Je n’ai pas touché au réglage swapiness (j’ai bien lu tous les posts qui disaient « ne pas toucher, Linux gère tout seul »), l’autre on dirait que je suis effectivement à 1Go:
Notez que j’ai lu pas mal de posts sur ce type de problème, j’ai constaté que c’était souvent compliqué et fastidieux, ma demande était surtout « comment faire un reset soft, sans avoir à redémarrer ».
Je suis bien d’accord que c’est mieux de résoudre la root cause, mais à défaut, parfois une solution moins optimale rend plus service (c’est juste un compromis pro/cons propre à chacun).
Bon, j’ai suivi déjà le conseil de redémarrer les plugins pour voir lequel serait en cause, et il semble que ce soit bien celui qui « rale » en premier: MQTT, qui pose pb. Après son redémarrage je passe de 17% à 66%.
Je suppose qu’une mise à jour arrête aussi tous les plugins et les redémarre après màj.
Bon pour l’instant rien de plus sur ce sujet, je mettrai le swapiness à 10 si ça revient autrement.
Mettre le swapiness à 10 ne diminuera pas l’utilisation mémoire. On commencera simplement à mettre de côté la mémoire peu utilisée plus tard plus tard.
En gros, on fonce contre un mur et on commence à freiner plus tard. C’est très biensi on sais que le mur ne sera atteint. Mais le swap n’aura moins de temps pour réagir si on a une fuite mémoire.
Quoiqu’il en soit, en cas de fuite mémoire, on finira tôt ou tard par en manquer. le seul moyen de récupérer la mémoire est de trouver le process responsable et de le redémarrer.
