Cherche “zeros”, et affiche tous les logs correspondants ici dans l’ordre.
cat ~/.config/duniter/gt/duniter.log| grep "zeros" 1 ↵
2017-11-13T10:18:50+01:00 - info: Generating proof-of-work with 4 leading zeros followed by [0-6]... (CPU usage set to 60%) for block#85725 HbTqJ1
2017-11-13T10:18:53+01:00 - info: Matched 3 zeros 000D3579722A66DD252D171222572CBA3DBE83FC49E257C1C34D8524FFB418BD with Nonce = 10700000000234 for block#85725 by HbTqJ1
2017-11-13T10:18:59+01:00 - info: Matched 3 zeros 00087B5765A1FAB353C45F5D2396C5CD0E693C277D0E971EAAD5CBCAA7C0A00E with Nonce = 10300000000766 for block#85725 by HbTqJ1
2017-11-13T10:19:02+01:00 - info: Matched 3 zeros 000A7289AFC1D5C66B521A6417874D30E2651F8986D2FD64B9163311B80E8304 with Nonce = 10100000001047 for block#85725 by HbTqJ1
2017-11-13T10:19:06+01:00 - info: Matched 3 zeros 000B86921D945645EDA3CE73E8635E204DC6AE34E36EB0F86C22277BFB07297E with Nonce = 10200000001452 for block#85725 by HbTqJ1
2017-11-13T10:19:09+01:00 - info: Matched 3 zeros 0002EBA92F363D29EDB06C5A830A89C031CD9CBD94344C3163136FFAC3E548D4 with Nonce = 10300000001708 for block#85725 by HbTqJ1
2017-11-13T10:19:10+01:00 - info: Matched 5 zeros 000008E3E6EAAC9C955EFC5C97CD4BD5A64269CEEA369BA9DA955AFC6FF2F687 with Nonce = 10500000001864 for block#85725 by HbTqJ1
2017-11-13T10:19:10+01:00 - info: FOUND proof-of-work with 4 leading zeros followed by [0-6]!
Ces logs paraissent tout à fait normaux, il te suffira de répéter l’opération quand tu estimeras qu’il y a un bug.
À noter quand même que durant la 1ère seconde de PoW il y a un essai pour déterminer où se trouve le 100%, afin d’ajuster le calcul pour atteindre la valeur de consigne (60% ici).
Toutefois c’est assez approximatif, et vu que tu as un octocores tu peux diminuer la PoW à 50% ou moins, ce qui te permettra largement de calculer des blocs, afin de faire quelques essais comparatifs et éviter l’utilisation de 100%.
Car il faut aussi voir l’utilisation CPU quand Duniter est en phase d’attente, je suppose que tu as d’autres programmes qui tournent sur ce serveur et qui viennent « fausser » le résultat de la mesure.
D’accord, il y a bien un moment où Duniter utilise le processeur à 100%, justement pour déterminer où se trouve ce 100%. Est-ce qu’il n’y a pas une situation ou le logiciel resterait bloqué dans cet état ?
EDIT : Okay donc j’ai quelque chose de beaucoup plus étrange. Mon noeud g1-test fonctionnait normalement, puis j’ai lancé mon noeud g1, et là c’est g1-test qui monte à 800%. Et il y reste même si je stoppe le noeud g1. Dans les logs le CPU usage est toujours à 60%.
Si j’avais découvert une telle situation, je l’aurais corrigée, c’est bien trop critique. Personnellement, je dirais que non, tu peux vérifier cela toi-même : https://github.com/duniter/duniter/blob/da85e4c3ba8e18a66b0c216335454473e1c205ae/app/modules/prover/lib/proof.ts#L114-L229
D’ailleurs il serait intéressant de sortir cet algo (finalement assez simple et relativement court) afin de le triturer dans un test unitaire.
Tu peux aussi suivre d’autres pistes, il y a déjà eu des cas d’utilisation à 100% du CPU sur ARM : Livrables ARM en attente : Raspberry PI 3 HS
Le problème dans ce cas était ailleurs, dans le gestionnaire de preuve. Une boucle infinie, il me semble.
Du coup maintenant je n’ai que g1-test (profil gt) qui tourne, et il reste à 800%. Il à commencé à atteindre les 800% quand j’ai lancé g1 (default_profile).
Je ne peux pas t’aider plus en l’état, il te faut faire d’autres tests en modifiant la valeur CPU.
Le CPU est un Intel Atom C2750. C’est du ARM ça ?
J’ai lancé duniter tout seul, il utilisait 100% d’un coeur pendant 10 secondes, puis est passé à 800%. dunitest lui n’étais pas lancé. Je vais refaire un reset data et lancer seulement 1 nœud, mais le fait que les 800% arrivent au moment où je lance le 2ème nœud me fait penser que ce n’est pas une coincidence.
Si les deux nœuds tournent à 60% chacun, ça fait donc 120% d’utilisation CPU (sur chaque cœur).
D’où l’intérêt de tester avec une autre valeur de CPU, par exemple 30%.
J’ai reset les 2 noeuds, et config dunitest à 30% du CPU. J’ai lancé uniquement dunitest, et j’ai en moyenne 85% sur chaque cœur. (cœurs logiques, je n’ai que 4 cœurs physiques).
EDIT : Au bout de 1 ou 2 minutes, il ne tourne plus que sur 1 cœur (en changeant à chaque refresh)
EDIT 2 : Après un restart, pas d’utilisation intensive.
EDIT alors que je suis en train d’écrire : Ca recommence : https://i.imgur.com/SME5UDq.png
Mon config.json : https://i.imgur.com/KAFMO4f.png
Peu importe les cœurs physiques ou logiques, Duniter ne regarde qu’en termes de cœurs logiques.
Visiblement il ne s’agit pas d’un ARM, mais possède des caractéristiques identiques : CPU à faible puissance destiné à de l’économie d’énergie. Or, Duniter utilise une règle un peu spécifique pour ARM en divisant la puissance CPU par deux pour atteindre la consigne.
Je te conseille donc d’appliquer cette même règle : si tu veux une utilisation à 30% de CPU pour chaque nœud, alors configure à 15% chaque nœud. Tu auras grosso-modo la bonne consigne.
En attendant, j’ai créé le ticket#1197 pour tracer le problème.
Avec cpu: 0.15 j’ai en moyenne 40% sur mes cœurs. Est-ce qu’il y a moyen de configurer sur combien de coeurs/threads le PoW est lancé ?
Tu peux modifier le fichier /opt/duniter/app/modules/prover/lib/constants.js, ligne 4 :
CORES_MAXIMUM_USE_IN_PARALLEL: 8,
Je relance mes 2 nœuds, et je te tiendrais au courant de la situation dans quelques heures.
Ca serait bien de l’ajouter dans config.json 
Fais-donc un ticket, sinon ce n’est pas tracé ! 
En fait je pense qu’il est possible de mettre le paramètre nbCores dans le fichier ~/.config/duniter/duniter_default/conf.json :
{
"nbCores": 3
}
Je fais déjà cela dans les tests automatisés, donc ça devrait passer.
Mais le ticket est quand même important pour rajouter cette option en ligne de commande.
Pourrais-tu lancer cette commande sur ton serveur et me donner le retour ?
node -e "console.log(os.arch())"node -e "console.log(os.arch())"
x64
Je pense pas que ça va t’aider beaucoup .