Jeedom 4.3.17 installé sur un RPI 4b, Debian 11.6, SSD mSata.
Depuis janvier ou février, je suis obligé de redémarrer le RPI tous les 5 à 6 jours, à cause de 3 problèmes :
le swap augmente chaque jour un peu plus jusqu’à saturer => je viens de voir que ce serait apparemment dû au plugin xiaomi-home, la « solution » est de redémarrer le daemon régulièrement.
plus inquiétant : quelque chose remplit la partie cache/buffer de la RAM, et ce dès le redémarrage du RPI.
des temps de réponses de plus en plus lents de Jeedom (parfois jusqu’à 1 minute pour charger certaines pages ou faire certaines actions, parfois immédiat pour les mêmes actions), mais pas que, c’est le système en général qui subit de grosses latences.
Ce que je ne comprends pas également, c’est que la même install clonée sur une carte SD fonctionne beaucoup mieux : le cache/buffer de la RAM n’est quasiment pas utilisé, et surtout il n’y a aucune latence, le système est très rapide.
Voici quelques copies d’écran pour illustrer :
Mes plugins :
Page Santé quand lancé depuis le SSD : on voit que le swap est utilisé, alors que lancé depuis la carte SD, le swap disponible est à 100% :
Je précise que j’ai utilisé le même port USB2 pour connecter soit la carte SD soit le SSD mSata.
Avant de me décider à poster ici, j’ai déjà passé des heures ou des jours à faire des tests, des recherches sur divers forum, sans vraiment progresser. Est-ce que quelqu’un a rencontré le même genre de problème, ou aurait une idée d’où chercher ?
J’ai remis les images.
A part le problème sur xiaomihome, je ne pense pas qu’il y ait un lien avec mon cas. Je n’ai pas fait d’upgrade de l’OS, mais directement une install de bullseye de 0.
Ok pour la solution paliative concernant xiaomihome, s’il suffit de redémarrer le démon régulièrement, ça se fait.
Par contre mon plus gros problème ce sont ces lenteurs irrégulières, et cette mémoire cache ou buffer utilisée au maximum quand je suis sur le disque SSD, et pas avec la carte SD, alors que l’un est un clone de l’autre.
Voici les données techniques de mon SSD :
J’ai un problème similaire avec un autre plugin. Un redémarrage du plugin règle le soucis.
Par contre je n’ai pas trouvé un moyen d’automatiser cette action, via un scénario par exemple.
Si quelqu’un a des idées, je suis preneur.
On voit bien qu’il s’agit de la mémoire cache (3,4 Go !) :
Alors que quand je démarre depuis la carte SD, à aucun moment je ne vois ce processus « systemctl status apache2 », ou alors il n’a pas le temps d’apparaitre.
Intéressant, je ne vois pas pourquoi ce process ferait à ce point là monter la conso…
Peux-tu passer la commande sudo ps auxfw pour voir à quel autre process est rattaché celui-là ?
S’agit-il toujours du même PID ou est-ce qu’il évolue dans le temps ?
Le PID reste le même tout le long, et le processus s’exécute pendant 1 minute et 45 secondes avant de disparaitre (mais la mémoire cache, elle, reste bien remplie).
J’ai désactivé la vérification d’apache dans ce fichier watchdog.php, redémarré, tout était correct niveau mémoire jusqu’à ce qu’apparaisse à nouveau le processus « systemctl status » mais cette fois pour le service vncserver. Donc il doit y avoir un problème du côté de systemctl, et pas Jeedom ou un quelconque plugin. Je pense que je suis bon pour une réinstall complète ?
Ou alors c’est le stockage qui a un pb, c’est anormal que systemctl prenne autant de temps.
Tu peux essayer de lancer à la main sudo systemctl status apache2 et voir ce qu’il raconte stp ?
Tu as installé une interface graphique sur ton Jeedom ?
Je ne sais pas trop si c’est supporté, mais ça n’aide certainement pas pour les perfs.
Tu as installé une interface graphique sur ton Jeedom ?
Je ne sais pas trop si c’est supporté, mais ça n’aide certainement pas pour les perfs.
oui, c’était plus rassurant au début (je ne connaissais quasiment rien à linux). Je n’ai pas un système domotique très développé, 5 ou 6 appareils zigbee, moins de 10 scénarios… je n’avais jamais eu de problème de performance auparavant.
Je me demande si le script qui check l’état d’apache avec cette commande n’est pas bloqué, tu as du faire control-C ou Q pour que la commande se finisse, on est d’accord ?
Après avoir démarré le RPI, la première fois que je lance la commande systemctl status pour n’importe quel service, cela tarde environ 1 minute 45 avant de voir s’afficher quelque chose :
Presque 3 Go de logs que le processus systemctl chargeait en mémoire cache.
Après avoir limité la taille du log à 200 Mo et redémarré, la commande systemctl status ne tarde plus que 1 ou 2 secondes la première fois, et la RAM reste au niveau attendu :
EDIT : comme indiqué par Bad dans le message suivant, éditer la valeur de RuntimeMaxUse au lieu de SystemMaxUse.
Et après tu oses dire que tu ne « connais quasiment rien à Linux »
C’est une très belle prise !
Je vais de ce pas regarder ce que ça donne sur mes systèmes
EDIT : Attention, je pense que SystemMaxUse= limite la taille des fichiers sur le disque et qu’il faudrait plutôt restreindre RuntimeMaxUse= (en mémoire), cf man 5 journald.conf.
A noter aussi : si la taille de tes fichiers de log explose, c’est peut être que tu as un problème ailleurs et qu’il faudrait consulter ces logs pour savoir ce qui les remplissent.
C’est en mettant les mains dans le cambouis qu’on apprend
Je n’ai rien trouvé de particulier, à part des ping vers la box internet toutes les minutes venant de jeeCron.php… (et même 3 ping par minute quand la box est éteinte) :
Passage sous Debian 11, Pi4 SSD mSata, reboote obligatoire car le Swap disparait à vue d’oeil.
Je n’arrive pas à trouver le coupable !
Dans ton cas, le plugin Xiaomi semble créer souvent cela (vu sur le forum). Je vais tester l’installation sur un autre Pi pour voir si le journal à aussi une telle taille.
