ressources utilisées par GW ???

[stephrac74]

Bonjour,

J'ai actuellement des fichiers logs sur un peu plus de 1 an. Je les coupe en général en périodes de 6 mois pour éviter d'avoir des fichiers de plus de 50Mo (un log par minute)

Je ne sais pas si c'est dû à cela, mais je trouve que GW est de plus en plus consommateur de ressources CPU et mémoire.
Actuellement il utilise 260 Mo de RAM et souvent pendant la création des différents graph il monopolise pendant plusieurs minutes 50% de mon dual core 2.3 GHz ! Autrement dit, il est entrain de bouffer toutes les ressources de mon PC ce que je trouve étonnant pour un logiciel de ce type qui devrait être plutôt léger.

Mes questions sont :
- d'autres observent ils le même phénomène que moi ?
- une idée de comment réduire les ressources demandées par GW ? Qu'est ce qui le fait mouliner de la sorte ?

Merci
Cordialement
Stéphane

[maxime1]

Cela a déjà été signalé à plusieurs reprises.

Dans mon cas GW peut utiliser jusqu'à 90% des ressources CPU sur mon portable pendant plusieurs heures ce qui entraine un plantage des autres programmes et je dois, parfois, le fermer.
Titoine travaille sur la version 3 de GW qui devrait être moins gourmande.
Mais je trouve que c'est un vrai problème pour les portables ou PC un peu ancien.
J'ai d'ailleurs envisagé de supprimer GW à cause de ça.

[stephrac74]

oui, actuellement il tourne sur mon pc principal et me bouffe bcp de ressources. Du coup j'ai prévu de le migrer sur une SBC (Single Board Computer) qui est un petit PC sur une petite carte, avec des performances réduites. Mais je commence à m'inquiéter de savoir si ça va pouvoir tourner dessus !

++
Stéphane

[TiToine]

La version 3 est 5 fois plus rapide, ca devrait soulager un peu le processeur.
Je devrais avoir quelque chose de fonctionnelle (une version alpha) vers Noël, patience donc.

[stephrac74]

cool... j'ai hâte de tester ça.

Merci pour ton travail


Stéphane

[Eric-Prog]

Bonjour,
je rencontre aussi ce problème de puissance processeur..
Je viens d'installer la dernière version, les deux processeur de mon core2duo fonctionnent à 100% durant la génération de graphique.
Quand GW est ouvert il mets environ 12 secondes à générer les graphiques !
Pourtant mon pc est dédié a ma station météo uniquement.

[jturlier]

Bonsoir,
c'est exact que GW est gourmand en ressources processeur, mais il y a cependant quelques "trucs" qui peuvent améliorer les choses en attendant la version 3 :
-des enregistrements de données toutes les 5 minutes minimum, c'est bien suffisant en météo
-Des mises à jour des stats toutes les 6 heures, de les faire toutes les 10 minutes ou même toutes les 30 ça n'a pas réellement de sens, puisque ce sont des stats et que pour les données du jour on les affiche avec d'autres moyens (graphes ou rapports)
-les exports de graphe toutes les 10 minutes mini
-Eviter les exports fréquents de données sur des périodes importantes
-Pour ceux qui travaillent avec des fichiers, plus leur taille est importante, plus il faut de temps pour les lire (en base de données le problème ne se pose pas puisque la gestion des données n'est pas faite par GW)

Je suis sûr qu'il y a encore d'autres recommandations, mais elles ne me viennent pas à l'esprit

Bonne soirée

Jean

[stephrac74]

-Pour ceux qui travaillent avec des fichiers, plus leur taille est importante, plus il faut de temps pour les lire (en base de données le problème ne se pose pas puisque la gestion des données n'est pas faite par GW)

Salut,

Veux tu dire qu'il y a un autre moyen que de passer par un fichier ? Je comprends pas bien là. De quelle base de donnée parles tu ?

a+
Stéphane

[TiToine]

C'est l'utilisation de fichiers texte (genre CSV) qui est problématique car pour lire la fin du fichier, il faut le lire entièrement ligne par ligne.
Rien que de faire une requête du genre "donne moi le dernier enregistrement connu", il faut tout lire.
Sur les fichiers binaires on avance juste l'index de lecture ou on veut et on lit, ce qui est plus rapide.

Pour la version 3 je vais essayer d'améliorer ca (y'a moyen en créant un genre de table d'indexation du fichier).

[endmarsfr]

C'est l'utilisation de fichiers texte (genre CSV) qui est problématique car pour lire la fin du fichier, il faut le lire entièrement ligne par ligne.
Rien que de faire une requête du genre "donne moi le dernier enregistrement connu", il faut tout lire.
Sur les fichiers binaires on avance juste l'index de lecture ou on veut et on lit, ce qui est plus rapide.

Pour la version 3 je vais essayer d'améliorer ca (y'a moyen en créant un genre de table d'indexation du fichier).

bonne idée,
l'utilisation d'une base de données "standard/ouverte" serait un réel plus.
Il y a plusieurs solutions gratuites simples à mettre en place :
- hsqldb (historiquement en java, mais il existe un portage en .net)
- sqllite
Le fichier CSV (d'Xnet par exemple) pourrait ne contenir que l'historique de la journée ou de la semaine
et le reste serait importé régulièrement dans une BD de ce type.

[jturlier]

Il y a plusieurs solutions gratuites simples à mettre en place :
- hsqldb (historiquement en java, mais il existe un portage en .net)
- sqllite

Bonsoir, ça pourrait-être effectivement intéressant, sauf que ces bases de données légères comportent de sérieuses restrictions, si par exemple tu prends SQLlite, tu n'as pas de datatype expressément défini et GW indique que le champ de date et heure est invalide.
Donc pour ma part, je pense qu'il vaut mieux utiliser les autres DB gratuites qui existent et qui sont plus conformes aux standards SQL 87/92/98 (et je les ai tous utilisés... même leur ancêtre le system R)
Si tu utilises une base de données et si elle possède un pilote ODBC, Graphweather fonctionne très bien.

Le fichier CSV (d'Xnet par exemple) pourrait ne contenir que l'historique de la journée ou de la semaine
et le reste serait importé régulièrement dans une BD de ce type.

Personnellement, je n'utilise pas Xnet, mais d'autres fichiers CSV, l'intérêt de ne pas se limiter à 8 jours de données, c'est que c'est un excellent backup (j'ai été très content de les avoir quand j'ai perdu des données MySQL en même temps que 2 disques Raid5... depuis je travaille avec PG, mais il en existe d'autres gratuites.

Pour Xnet, je crois d'ailleurs savoir que Jos à travaillé sur un module SQL. Je suis sûr que ce serait une excellente nouvelle s'il avait un moment pour le publier. Dbexpress ayant maintenant un diver ODBC, ce serait certainement un rêve pour de nombreux utilisateurs de Xnet.

Bonne soirée à tous

Jean

[pat46fr]

Bonjour, je vais peut être dire une bêtises mais tant pis (une de plus ou de moins.......). Les stations des utilisateurs de ces fichiers csv ne fournissent elles pas un fichier avec les données en temps réel toutes les 4 ou 5 secondes? Si oui, "suffit" de récupérer ces données et de les mettre dans une base SQL (ou autre) et ensuite que GW aille lire cette base, non?

Pat

[jturlier]

Salut Patrick,
ce que tu suggères ne serait pas mal, mais toutes les stations ne le font pas, et le résultat serait le même qu'avec ce que tu as actuellement : Il faut un prog pour récupérer ces données et les mettre dans une DB. Le Hic, c'est qu'enregistrer toute les 4 ou 5 secondes serait une véritable folie. Il faudrait donc pour être dans une situation classique, conserver les données pendant 5 ou 10 minutes suivant le pas d'enregistrement utilisé, Puis faire des moyennes... Par contre ça permettrait de récupérer les pics (ce que certaines stations te donnent aussi en direct)

Cdlt

Bonne journée et à bientôt

[pat46fr]

Salut Patrick,
Il faudrait donc pour être dans une situation classique, conserver les données pendant 5 ou 10 minutes suivant le pas d'enregistrement utilisé, Puis faire des moyennes... Par contre ça permettrait de récupérer les pics (ce que certaines stations te donnent aussi en direct)

Salut Jean
Bon, la neige a fondue par chez toi apparemment

Les grands esprits se rencontrent on dirait, lol. Ce que tu dis, c'est ce que je fais actuellement. Au moins pour le vent (vu que c'est ce qui a le plus de pics), je lis le curdat toutes les 5 secondes, je mets les valeurs de vent dans une table "temporaire" et au bout de 10 mns, moyennes et maxi des valeurs puis rajout des autres valeurs du curdat et on stocke. Ca fait juste un script php qui tourne en continu, pas trop gourmand. Et en plus écrit par ma pomme donc sans doute pas dans les règles de l'art, lol.

Sur ce , bonne continuation et à plus

Pat

[TiToine]

J'ai ajouté une sonde pour le vent sur 10 minutes dans la version 3 de GW...elle pourra donc être lu sur un DB MySQL ou dans un CSV (ou calculée si le pas d'enregistrement de la vitesse du vent est assez petit).