Oui mais lequel.
Tu ne peux pas choisir sur quel cœur tu lance ton programme, c’est l’OS qui le gère il me semble.
Donc plutôt que de diviser par deux le pourcentage cpu on devrait diviser par deux le nombre de cœurs ? Dans ton cas par exemple tes 8 cœurs logiques correspondent à 4 cœurs physiques c’est ça ?
Ah oui bien sûr. C’est le nombre de cœurs qu’il faut diviser par 2, pas l’occupation d’un cœur. Par contre c’est justement bizarre que l’occupation d’un cœur ne corresponde pas à la config.
1 Like
@nanocryk peut tu tester un noeud de dev sur ta machine pour voir si le nouveau comportement est adéquat (a savoir diviser le nombre de coeurs par 2 plutot que le taux cpu).
Il te suffit de cloner de dépot, de te placer sur la branche dev puis de lancer yarn 
En fait je pense que c’est au moment de l’évaluation du score pour étalonner les 100% que Duniter se fait tromper par l’Hyperthreading et évalue un taux supérieur a la réalité ! Bref, finalement il vaut peut etre mieux rester sur tout les coeurs logiques mais diviser par 2 le taux cpu comme l’a fait cgeek initialement, qu’en pense tu ?
1 Like
Comme dis précédemment, pourquoi vouloir le rendre multi-thread si on ne fait pas de course à la puissance ?
Parce nodejs est fondamentalement multi processus et que c’est une de ses forces, il vaut mieux étaler sur tout les cœurs logiques plutôt que de se concentrer sur quelques uns. En plus je n’aime pas l’idée de brider un utilisateur en l’empêchant d’utiliser tout ses cœurs logiques s’il le souhaite, et pour les autres j’ai mis en place l’option --nb-cores 
1 Like
@nanocryk avec la 1.6.13 arrive tu a un résultat satisfaisant en réglant un taux cpu faible, en bref est-ce juste une double évaluation du taux ou est tu toujours à 100% quel que soit le taux réglé ?
Avec les configs faites ("cpu": 0.3, "nbCores": 1) c’est correct, mais au niveau de l’utilisation effective ça ne correspond pas vraiment. J’ai 2 duniters qui tournent (g1 et g1-test) et chaqu’un utilise 1 cœur à 80%, cependant des fois ce 80% se retrouve réparti sur 2 cœurs (56%+24%). Donc le 0.3 n’a pas vraiment de sens, car ce n’est ni 30% ni 60% (cette histoire de doublon).
1 Like
@nanocryk ok donc c’est juste la méthode d’évaluation du taux cpu qui s’étalonne mal, le problème c’est que ça dépend de tes performances au moment de l’étalonnage donc de ton environnement d’éxécution a ce moment là, c’est assez aléatoire en fait. je constate aussi chez moi que le taux réel est plus élevé que le taux théorique mais pas d’autant (environ 15% de plus).
bref ce n’est pas critique donc ça attendra la 1.7, j’ouvre un ticket mais je ne vois pas trop ce qu’on peut faire pour affiner l’étalonnage : https://github.com/duniter/duniter/issues/1199
2 Likes
Il faut bien comprendre que le %CPU n’est qu’une tentative d’approcher cette consommation. Or si lors de l’étalonnage le résultat est faussé par le système, alors le calibrage sera mauvais et il résultera un comportement totalement déphasé avec la consigne.
Il est toujours possible d’améliorer la situation en modifiant l’algorithme pour avoir un ajustement dynamique, mais ça reste à développer. Il faut alors faire appel à des fonctions de NodeJS de monitoring CPU, entre autres.
Comme dirait l’autre « c’est facile, il suffit de le faire ».
2 Likes
Je comprends, pas de problème. De toute façon avec cette config la consommation est correcte, donc plus de problème pour moi. A voir plus tard s’il y a moyen d’améliorer ça par défaut.