Soucis d'affichage sur seulement quelques graphes

[dvb]

Bonjour à tous,

Je rencontre des soucis avec QUELQUES graphes.

• délais TRES longs (*) avant affichage à la première ouverture.
• délais TRES longs (*) avant affichage si je change d’échelle (jour, heure, 30mn,…)
• au survol du graphe, horodatages et valeurs ne s’affichent plus.

A part ce phénomène localisé, pas d’autre souci côté Jeedom :

• Jeedom v4.3.23 sous Debian 11.
• Système à jour+ RAS côté santé.

J’aimerais ne pas perdre ces historiques (températures et production solaire).

Vu que le graphique s’affiche , je me dis que c’est peut-être sauvable.
Qu’en pensez-vous ? Y a-t-il une possibilité de réparer ça ?

Merci.

(*) le navigateur me demande même si je veux attendre.

[Fifirept]

Bonjour,

Pour commencer, ton post concerne plus le core de Jeedom que le plugin Virtual.
Ensuite, tu ne parles pas de la machine qui héberge ton Jeedom (Raspberry, autre ? / SD, SSD ?).

Ce que tu décris me fait penser au fait de tracter une remorque de camion avec une 2CV.
A 1ère vue, je dirais :

• Lisser les données supérieures à 1 ou 2 mois.
• Passer sur un support un peu plus véloce.

Quel est le résultat du benchmark de la page Santé ?

[dvb]

@Fifirept

Pour commencer, ton post concerne plus le core de Jeedom que le plugin Virtual.

J’ai hésité… Effectivement, je laisse les admins déplacer le post si nécessaire.

@Fifirept

Ensuite, tu ne parles pas de la machine qui héberge ton Jeedom (Raspberry, autre ? / SD, SSD ?).

C’est volontaire → le défaut étant limité à quelques graphiques, je considère le matériel hors de cause.

Les infos :

• Jeedom est hébergé sur une VM sous Proxmox.
• Proxmox sur Intel i5-13500T + SSD NVME 1Go Kingston + 64 Go de RAM
• VM Jeedom surdimensionnée :
  

@Fifirept

Ce que tu décris me fait penser au fait de tracter une remorque de camion avec une 2CV.

Euh non pas vraiment

@Fifirept

• Lisser les données supérieures à 1 ou 2 mois.

Je veux absolument éviter, sinon l’historique ne sert plus à rien.

@Fifirept

• Passer sur un support un peu plus véloce.

Ce n’est pas ça vu la plate-forme utilisée.

@Fifirept

Quel est le résultat du benchmark de la page Santé ?

Test effectué à l’instant :

[echo]

Bonjour

Si je compare avec mon Nuc Proxmox :

Le memory usage élevée, j’ajouterais de la mémoire pour test.

[dvb]

@echo

Si je compare avec mon Nuc Proxmox :

Le memory usage élevée, j’ajouterais de la mémoire pour test.

J’avais vu la consommation de RAM, mais mis ça sur le compte de la gestion Linux…
10 Go c’est vraiment beaucoup, du coup je voudrais creuser avant d’en ajouter davantage :

1) Peux-tu me donner tes valeurs pour comparer ?

• Mon swapiness est à 10%
• Mon swap est à 8Go
• Mon tmpfs est à 2 Go

2) Je vois que htop m’affiche énormément de lignes mariadb. Est-ce normal ?

[Loic]

Bonjour,
Les graphs ya une grosse partie coté navigateur en particulier tous ce qui est au survol, donc a voir sur ton pc a toi deja, quel navigateur aussi et si ya bien un lissage car si trop de point le navigateur gelere et c’est lent.

[echo]

Ma config :

Par contre un swap à 8 Go me semble démesuré, sur les vieilles machines on calculait Swap= mémoire/2. Maintenant on peut mettre un swap beaucoup plus petit. Bon c’est pas le problème puisque tu as en swap consommé 586M mais moi je suis toujours à 0. Donc cela veut dire que le besoin en RAM est supérieur à 10 G. Il faut donc faire une analyse plus fine de la consommation. Il faut travailler en CLI avec SSH et fermer l’explorateur.

Concernant les PID Mariadb = 40 lignes

Une quarantaine de plugin.

[dvb]

@Loic

Les graphs ya une grosse partie coté navigateur en particulier tous ce qui est au survol, donc a voir sur ton pc a toi deja

Salut Loïc,
J’ai essayé avec deux machines récentes :

• PC n°1 (ethernet) Debian → Firefox et Chrome.
• PC n° 2 (WiFi ac) Debian → Firefox et Chrome.

J’ai les mêmes résultats (la majorité des graphes OK, quelques un en anomalie).
→ Je pense que cela les met hors de cause.

@Loic

si ya bien un lissage car si trop de point le navigateur gelere et c’est lent.

Je viens de comparer quelques graphes. J’en ai plusieurs sans lissage qui fonctionnent normalement (historique > 1 an).

Si je fais du lissage, l’historique n’est plus le reflet des vraies valeurs, cela ne me servirait à rien températures et puissance solaire erronés).

Le fait d’avoir pleins de lignes mariadb n’est pas un souci ?

@dvb

[Loic]

C’est ligne sont normal.
Pour le lissage ce qui compte c’est pas qu’il soit activé ou non c’est le nombre de point, si une commande a une valeur par jour lissage ou pas lissage ca change rien, si par contre ya une valeur par seconde ou par minute alors la il faut un lissage sinon le graph est long a s’afficher.

[echo]

Sur tes vues graphiques est ce que tu as un petit triangle avec un point d’exclamation comme cela :

J’ai cette erreur sur une vue où j’ai beaucoup de graphiques. Je vais alléger.

Pour revenir au swap si tu as une consommation ton système sera inévitablement ralenti puisque le swap est sur un disque SSD ou pas. Moins rapide que la mémoire RAM.

[dvb]

@echo

Sur tes vues graphiques est ce que tu as un petit triangle avec un point d’exclamation comme cela :

J’ai eu cette erreur il y a longtemps, mais RAS actuellement. Je vais être attentif au cas où.

@echo

Pour revenir au swap si tu as une consommation ton système sera inévitablement ralenti puisque le swap est sur un disque SSD ou pas. Moins rapide que la mémoire RAM.

+1
J’ai mis 8 Go pour être tranquille, mais Jeedom ne l’utilise quasiment pas (580Mo / 8Go dans la vue htop).

[dvb]

@echo

Par contre un swap à 8 Go me semble démesuré, sur les vieilles machines on calculait Swap= mémoire/2. Maintenant on peut mettre un swap beaucoup plus petit. .

J’ai gardé l’habitude du 1 pour 1 car cela permet l’hibernation.
Mais sur un Debian Jeedom, aucun intérêt c’est clair …

@echo

Bon c’est pas le problème puisque tu as en swap consommé 586M mais moi je suis toujours à 0.

Bonne remarque. Du coup je vais passer à 16Go ce soir, et regarder le comportement.

@echo

Donc cela veut dire que le besoin en RAM est supérieur à 10 G. Il faut donc faire une analyse plus fine de la consommation. Il faut travailler en CLI avec SSH et fermer l’explorateur.

+1 En fonction des résultats du 16Go, j’irai analyser la consommation de plus près.

A suivre…

[echo]

Bonjour

Tu peux mettre 16 Go.

En premier lieu : je ferais un reboot de jeedom puis en cli sur la VM sur Proxmox lancer htop. Relève la mémoire après 10mn pour laisser le temps au système de s’initialiser, ne pas ouvrir Jeedom sur l’explorateur.

Puis tu ouvre Jeedom sur l’explorateur et tu te positionne sur l’affichage des graphiques où l’affichage est lent. Et tu relève à nouveau la mémoire.

Je suppose que pour l’affichage de l’historique, les points qui sont en base de données sont chargés en mémoire. D’où la consommation excessive de ta mémoire. Augmenter la mémoire augmentera la vitesse d’affichage.
Mes historiques date de février je vois pas une grosse consommation de la mémoire quand j’affiche les graphiques.

[dvb]

Très clair merci @echo
Je m’y colle…

[dvb]

Résultats détaillés sous Jeedom v4.3 stable

1. Debian 12 et mon Chromium habituel : v123.0.6312.86

1. htop au reboot
   

   

2. htop 10mn après reboort
   

   

3. htop sur ouverture navigateur page design
   

   

4. htop sur ouverture graphe lent
   

   

5. Page santé Jeedom et résumé Proxmox OK
   

   
   
   
   

6. Bench équivalent à ceux d’il y a quelques jours
   

Au final :

• Usage RAM redescendu très bas et utilisation swap à 0.
  → Je vais quand même surveiller la consommation
• Nette amélioration du temps de chargement « graphe lent » descendu à env 6s.
• Changement d’échelle (ex. semaine → jour) même timing et gain.
  → mais les deux restent trop élevés de mon point de vue.
• Dates et valeurs toujours pas affichées.

2. Sous Debian 12 et Firefox 115.9.1esr

• temps de chargement « graphe lent » un peu plus rapide (env 5s).
• Changement d’échelle (ex. semaine → jour) bien plus rapide → env 2s.
• Les dates et valeurs sont bien présentes sur tous les graphes !

Conclusion :

• Grosse amélioration a priori grâce à la RAM.
• Les graphes lents mettent encore de 5 à 6s à charger selon les navigateurs.
• Le changement d’échelle est bien rapide sous Firefox.

[EDIT]

• Firefox affiche dates et valeurs sur TOUS LES GRAPHES.
• Chromium OK en v123.xx
• Chromium KO en v90.xxx (je vais actualiser le navigateur sur cette machine)
• Firefox est plus rapide pour certaines actions (meilleur cache ?)

→ Il reste une problématique de vitesse, peut-être en amélioration avec Jeedom 4.4 ?

[Loic]

Bonjour,
Je sais pas trop quoi te dire ni comment optimiser, je suis meme pas sur ca soit possible, ca dépend toujours du nombre de valeur en historique et ca j’ai rien trouvé la dessus dans le poste. Il faudrait voir combien yen a pour les rapides et pour les lents.

[dvb]

Bonjour Loic,
Comment faire pour mesurer ça ?
(Si ce n’est pas trop compliqué je peux regarder).

[Loic]

C’est une requête du genre
SELECT count(*) ROM history WHERE cmd_id=TODO AND datetime>=TODOAND datetime<=TODO

Et

SELECT count(*) ROM historyArch WHERE cmd_id=TODO AND datetime>=TODOAND datetime<=TODO

En additionnant les 2 valeurs pour avoir le total, bien remplacer les todo par les bonne valeur (id de la commande, min datetime et max datetime).

[dvb]

OK merci Loïc !

[dvb]

Je viens de jeter un œil à la conso mémoire qui a remonté. Sous Chromium v2123, j’ai reperdu l’affichage des dates et valeurs sur les « graphes lents ».

Il y a un truc qui m’échappe dans les stats :

• Proxmox et htop affichent une utilisation quasi totale.
• Santé Jeedom non.
• je ne vois pas de gros consommateur dans htop

Comment exploiter ces résultats et trouver le consommateur ?
(Du coup je passerai à 16 Go ce soir pour voir si cela améliore).