Bonjour,
J’ai commencé à faire monter ma Luna en charge et elle commence deja a coincer au niveau performance.
Je me demande s’il n’y a pas un souci avec le swap:
Est-ce que d’autre personnes ayant une Luna on aussi le swap qui est inconnue?
Si c’est une erreur de parametrage, est-ce que vous savez comment le résoudre?
J’ai pire que toi: espace disque 63% et espace tmp: 99%
Mémoire suffisante: j’ai 0 et pas de point d’interrogation ! je ne sais pas à quoi ca correspond…
J’ai abandonné la Luna en prod. Je trouvais les temps de réponses trop important.
Je suis repassé sur une VM et j’utilise la Luna avec Jeedom Link pour contrôler les appareils Zigbee et Zwave.
OvO
Bonjour,
Suite à des problèmes de performance, j’ai ouvert un ticket au support qui m’a confirmé qu’il n’y avait pas de swap activé sur la Luna volontairement.
Ayant beaucoup d’équipements’ j’ai quand même mis 1go de swap. Mais je dois rebooter tous les 4 jours.
Pour ma part c’est le plugin xiaomi qui consomme énormément de mémoire.
Mais je rejoins le commentaire précedent, j’ai beaucoup d’équipement et la Luna est trop juste en performance. Je vais retourner sur une VM
Bonjour,
Même inquiétude, le swap « perd » 15% tous les jours.
A partir de combien d’équipement peut-on dire que la Luna devient « trop juste » ?
Perso, j’ai 120 équipements 978 commandes, et je dois rebooter toutes les semaines aussi…
Est ce que j’ai choisi la bonne box ???
Bon ce soir c’est la goute d’eau. Encore un problème. Pas de fiable du tout. Je retourne sur une VM avec mon synology.
Je renvoie tout a domadoo. J’avais même acheté la version 4G, même problème. Je trouve que c’est dommage car la version 4G avait tout pour elle, elle est quasiment autonome. La bascule en 4G se faisait bien et rapidement.
Petits changements depuis un mois : 121 équipements, 982 commandes, plus quelques mises à jour plus tard, maintenant, je « perds » 40% de swap tous les jours…
Donc sur les conseils de la hot line, redémarrage tous les 2 jours… pfffff
Je regrette effectivement ce choix…
La batterie et le plugin dédié alarme m’avaient parus intéressant au moment où la sirène de mon alarme a rendu l’âme et ma box eedomus a complètement planté (la même semaine). Le support eedomus ne m’a jamais répondu, au bout de 10 jours sans domotique, j’ai fait le choix de « tout changer »…
De plus, n’étant pas informaticien, la solution jeedom n’est vraiment pas facile…
Merci de l’intérêt à mon soucis.
Mes plugins : Agenda, Alarme, App mobile, Data export, Enedis, EnOcean, Gcast, Google smarthome, Jeeasy, Luna, Mail, Mode, MQTT (mais que je n’utilise pas, je ne sais pas faire), Openvpn, Personnal Weather Station, RTE Ecowatt, Script, Sons, Thermostat, Virtuel, Weather, Z-Wave JS, Zigbee.
Pour les scénarios, je ne sais pas… je ne suis pas informaticien.
Je fais donc simple à priori (63 scénarios). Comment peut-on contrôler cela ?
Pour les scénarios, vous pouvez déjà regarder le moteur des tâches.
Mieux encore, vous avez la possibilité de couper tous les scénarios d’un coup, histoire de voir en 1 ou 2 jours, voir moins, si votre Jeedom ne va pas mieux.
Pour le plugin mqtt, c’est utilisé par le plugin Z-waveJS entre autre.
Dans le moteur des tâches, tout est « arrêté » en général. Bien sûr, suivant les scénarios, il y en a en « démarrage » ou « en cours ».
Arrêter les scénarios est une solution que je vais tester (par exemple, je n’utilise pas le chauffage en ce moment, j’ai 27 scénarios pour le chauffage).
50 heures entre le dernier redémarrage et l’alerte Jeedom (15% de swap).
Quel est le « risque » lorsqu’on est à zéro ? (lorsque j’ai redémarré ce matin, le swap dispo était à 0).
Cet été, je vais être absent 32 jours, dont la plupart seront sans internet… je ne pourrai pas redémarrer à distance, comment programmer un redémarrage automatique. A chaque redémarrage, certains volets s’ouvrent, d’autres se ferment, certaines fois j’ai des lumières qui s’allument. La porte du garage ne s’est jamais ouverte mais je m’inquiète…
Bonsoir.
J’ai l’impression que vos inquiétudes sont peut être infondées.
Le swapiness donne le % de mémoire (RAM) disponible en dessous duquel le système va utiliser le disque dur local comme espace de mémoire étendue. Donc en théorie avoir un swapiness à 0% signifie que le système ne fera appel au disque dur qu’en dernier recours. Inversement un swap à 100% signifie que le système utilisera systématiquement le disque dur comme mémoire.
Bien entendu lorsque la mémoire RAM est trop faible pour une machine le swap va être utilisé en quasi permanence et ralentir la machine in fine. Avec un disque dur de type SDD cela est moins flagrant mais reste vrai.
Un swapiness supérieur à 20% est un seuil en dessous duquel il n’est pas recommandé de descendre.
Le swap va évoluer au cours du temps puisque le système va l’utiliser dès que le % de réserve RAM sera atteint.
Il va vider de cette RAM les environnements des process inactifs à un moment donné pour les passer sur le disque dur, libérant ainsi une partie de la RAM.
Le principe inverse va s’effectuer lorsque le process dont l’espace mémoire a été mis sur le disque dur devra repasser à actif. Le système va vider la RAM actuelle sur le disque dur et la remplir avec les données du process antérieurement sauvegardé sur le disque dur.
D’où le nom de swap (échange).
Effectivement plus la RAM est de taille réduite plus ce principe de swap va être appelé souvent , générant des ralentissements de la machine (cf plus haut).
Cela est un fonctionnement normal de Debian, donc ne pas s’alarmer inutilement lorsque le swap baisse au cours du temps. Ce n’est que le reflet d’une mémoire qui se vide et se remplit dynamiquement en fonction des besoins d’exécution de la machines elon un seuil fixé par le swapiness
Je suis totalement en phase avec ce qui dit @Yves19
L’augmentation du swap peut être un symptôme d’un autre pb, mais ca ne justifie pas en tant que tel qu’il y a un pb, puisque c’est le fonctionnement normal d’un systeme linux que d’utiliser ce .
Vous pouvez par contre vous assurer qu’il n’y a pas une augmentation croissante et régulière de la memoire. Ceci peut etre un sympltome de fuite mémoire qui peut faire planter votre systeme lorsque cette dernière à tout rempli.
pour rebooter votre jeedom regulierement (mais attention à ne pas masquer un pb en faisant ceci !), il suffit de créer un scenario planifié avec la fonction jeedom_reboot :
Ca c’est inquietant … en quoi un reboot lancerait des commandes d’ouverture. Je passerait plutot du temps à essayer de comprendre ce qui se passe sur ce point là
Information « rassurante », et merci pour ces explications, mais pourquoi jeedom monitoring m’envoie un message d’alerte en dessous de 15% de swap disponible.
Et comment réagir à mes échanges avec le support ? Donc il suffit de re-démarrer quand j’ai ce genre d’alerte ? A priori oui , c’est ce que nous préconisons.
100% d’accord, ce n’est pas une réaction normale.
Il faut traiter ce sujet rapidement, il fait comprendre si ce sont des scénarios qui s’exécutent au redémarrage ou des commandes, et fiabiliser l’ensemble…