J’avais ce problème avec la 1.6.10, et il persiste en 1.6.13. Maintenant dès que je le lance l’utilisation processeur est à 100% sur tous les cœurs. Quand j’avais installé la 1.6.10 il y a quelques jours, pas d’utilisation intensive. Je vais refaire la synchro et re-télécharger la blockchain, mais dans tous les cas ce n’est pas normal qu’il utilise tous mes cœurs, mais avec une desynchro.
Il aurait fallu regarder les logs à ce moment là, voir notamment si la conf CPU était indiquée à 100% ou pas.
Je n’ai pas changé la conf CPU, elle à donc sa valeur par défaut. Pendant plus d’une semaine tous les cœurs étaient à la limite de l’idle, et je minais des blocs sur g1-test. Aucune autre action sur le serveur entre cette vérification et aujourd’hui.
Je ne dis pas que tu l’as mise à 100%, mais peut-être qu’un bug aurait fait changer sa valeur et alors les logs auraient montré cela.
J’ai fait un reset data, est-ce que les logs ont été effacés ? Sinon, où sont-ils ?
Ils sont dans le dossier ~/.config/duniter/duniter_default/, fichier “duniter.log”.
Mais le reset supprime ce fichier.
Je viens de finir la sync de g1-test, et au lancement je retourne à 100% sur tous les cœurs. Qu’est ce que je dois chercher dans les logs ?
EDIT : Les 100% sont restés pendant une 10ène de secondes, et maintenant j’ai en moyenne 100% d’un cœur (qui est reparti sur plusieurs cœurs, genre cœur 1 à 40% + cœur 2 à 60%, et qui change à chaque rafraîchissement de htop)
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.