Duniter plante pour manque de mémoire

Nodes Duniter-v1
1

J’ai enfin une machine avec un peu de place pour faire tourner un nœud Duniter (il me semble que le réseau en a besoin). Vous avez peut-être vu passer g1.trentesaux.fr, mais celui-ci crash environ une minute après le lancement :

<--- Last few GCs --->

[975562:0x27d3860]   236287 ms: Scavenge 1394.8 (1422.2) -> 1394.1 (1422.7) MB, 6.0 / 0.0 ms  (average mu = 0.139, current mu = 0.083) allocation failure
[975562:0x27d3860]   236294 ms: Scavenge 1394.9 (1422.7) -> 1394.3 (1423.2) MB, 3.3 / 0.0 ms  (average mu = 0.139, current mu = 0.083) allocation failure
[975562:0x27d3860]   236299 ms: Scavenge 1395.0 (1423.2) -> 1394.4 (1424.2) MB, 3.6 / 0.0 ms  (average mu = 0.139, current mu = 0.083) allocation failure


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x268f524dbe1d]
Security context: 0x171e8401e6c1 <JSObject>
    1: DoJoin(aka DoJoin) [0x171e84005e69] [native array.js:~87] [pc=0x268f5273c5d0](this=0x1e13f64026f1 <undefined>,l=0x000c49728001 <JSArray[33]>,m=33,A=0x1e13f64028c9 <true>,w=0x171e8405d831 <String[1]: ,>,v=0x1e13f64029a1 <false>)
    2: Join(aka Join) [0x171e84005eb9] [native array.js:~112] [pc=0x268f52749838](this=0x1e13f64026f1 <undefined>,l=0x000c497...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x8fb090 node::Abort() [/opt/duniter//node/bin/node]
 2: 0x8fb0dc  [/opt/duniter//node/bin/node]
 3: 0xb031ce v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/duniter//node/bin/node]
 4: 0xb03404 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/duniter//node/bin/node]
 5: 0xef7462  [/opt/duniter//node/bin/node]
 6: 0xef7568 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/opt/duniter//node/bin/node]
 7: 0xf03642 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/opt/duniter//node/bin/node]
 8: 0xf03f74 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/duniter//node/bin/node]
 9: 0xf06be1 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/opt/duniter//node/bin/node]
10: 0xed682b v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/opt/duniter//node/bin/node]
11: 0x11c5678 v8::internal::Runtime_StringBuilderJoin(int, v8::internal::Object**, v8::internal::Isolate*) [/opt/duniter//node/bin/node]
12: 0x268f524dbe1d
/usr/bin/duniter : ligne 15 : 975562 Abandon                 $NODE "$DUNITER_DIR/bin/duniter" "$@"

Par défaut la variable NODE_OPTIONS n’est pas set, et j’ai essayé de la mettre à 6Go avec export NODE_OPTIONS="--max-old-space-size=6144" mais ça ne change rien. De plus, htop ne montre pas d’utilisation abusive de mémoire (<2Go)

Méthode d’installation : paquet debian hotfix 1.8.2.

Je n’ai pas trouvé de sujet récent qui en parle :mag:, comment font les #Blacksmith en ce moment ?

2

Rencontres-tu ce problème avec la v1.8.1 ?
Pour s’assuser que rien d’autre n’a changé entre-temps.
Beaucoup de temps s’est écoulé entre les deux releases. Peut-être une version mineure de Nodejs change la donne ?

Autrement, si tu n’observes pas de saturation de la mémoire vive lors du démarrage, ça ne va pas être simple à débugger.

Peux-tu nous donner un peu plus de contexte. ARM ? Combien de RAM disponible ? Debian ? Quelle version de Debian ? Peut-être que Nodejs intégré n’est pas compatible.

1 Like
3

Pour le contexte, c’est assez basique : debian bullseye x86_64, 12Go de ram, j’ai tué mes autres services pour être sûr d’avoir toute la ram dispo pour Duniter.

Il faut que j’essaye les versions antérieures, je vais aussi essayer une compilation manuelle et changer de version de nodejs. Pour l’instant j’ai

edit: non pertinent 
$ apt info nodejs
Package: nodejs
Version: 12.22.5~dfsg-2~11u1

(d’ailleurs je ne sais pas comment nodejs s’est retrouvé installé, je ne l’ai pas fait il me semble)

$ /opt/duniter/node/bin/node --version
v10.20.1

Mais ça m’arrangerait que quelqu’un ait rencontré le même problème, je préférerais consacrer le peu de temps que j’ai pour me mettre à jour avec Duniter-v2s et Ğecko-v2s. Donc je vais attendre un peu avant de faire les tests.

4

Tes logs indiquent que ça utilise nodejs intégré au paquet Duniter. Nodejs intégré est en v10 et Duniter n’est compatible qu’avec cette version.

1 Like
5

La dernière fois que j’ai vu cette ligne, c’est parce que j’avais installé la version x86_64 sur une architecture ARM. Ça n’a sans doute aucun rapport avec ton problème, mais je le dis à tout hasard.

1 Like
6

Encore un mystère, ça n’a pas planté depuis hier…

[edit]

quelques jours plus tard il a planté avec

/usr/bin/duniter : ligne 15 : 976483 Processus arrêté      $NODE "$DUNITER_DIR/bin/duniter" "$@"

toujours aussi mystérieux

7

J’ai observé que l’ajout de gros blocs fait crashé Duniter.
Tu peux remédier à ça avec un contournement avec le système d’initialisation.
Dans le cas de systemd :

Restart=on-failure

Il redémarre et ajoute le bloc qui l’a tué comme un grand.

Il suffit de chercher dans les logs une ligne de démarrage pour observer ce comportement :slight_smile:

1 Like
8

Premier bug depuis avril, toujours le même message :

/usr/bin/duniter : ligne 15 : 1017271 Processus arrêté      $NODE "$DUNITER_DIR/bin/duniter" "$@"

Je n’ai pas mis de restart on failure, je préfère faire manuellement, ça me donne une idée de la fréquence à laquelle ça crashe et ça avertit les utilisateurs que mon nœud n’est pas dans des conditions très fiables :smiley:

9

Encore un bug

/usr/bin/duniter : ligne 15 : 1323459 Processus arrêté      $NODE "$DUNITER_DIR/bin/duniter" "$@"

C’est pas si fréquent.

10

au cas où, QEMU est un logiciel libre de machine virtuelle, pouvant émuler un processeur

11

Cette fois-ci, ça a l’air d’être un plantage plus intéressant :

2023-06-04T19:14:16+02:00 - info: Block resolution: 1 potential blocks after current#632434...
2023-06-04T19:14:18+02:00 - info: WS2P: init: bundle of peers 1/10
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - info: Blocks were not applied.
2023-06-04T19:14:18+02:00 - error: Unhandled rejection: [object Object]
2023-06-04T19:14:18+02:00 - error:  httpCode=400, ucode=1015, message=Document already under treatment
2023-06-04T19:14:19+02:00 - info: Block #632435 added to the blockchain in 1144 ms
2023-06-04T19:14:19+02:00 - debug: Opening SQLite database "/home/hugo/.config/duniter/duniter_default/wotwizard-export_0.db"...
2023-06-04T19:14:19+02:00 - error: Error [ERR_IPC_CHANNEL_CLOSED]: Channel closed
    at ChildProcess.target.send (internal/child_process.js:636:16)
    at Worker.send (internal/cluster/worker.js:40:28)
    at PowWorker.sendCancel (/opt/duniter/app/modules/prover/lib/PowWorker.js:81:27)
    at slaves.forEach (/opt/duniter/app/modules/prover/lib/powCluster.js:121:22)
    at Array.forEach (<anonymous>)
    at Master.cancelWorkersWork (/opt/duniter/app/modules/prover/lib/powCluster.js:120:21)
    at Master.cancelWork (/opt/duniter/app/modules/prover/lib/powCluster.js:130:14)
    at PowEngine.cancel (/opt/duniter/app/modules/prover/lib/engine.js:43:29)
    at WorkerFarm.stopPoW (/opt/duniter/app/modules/prover/lib/blockProver.js:70:53)
    at BlockProver.cancel (/opt/duniter/app/modules/prover/lib/blockProver.js:122:24)
12

Aucune erreur ne peut exclure un manque de mémoire, puisque les effets sont imprévisibles, comme par exemple empêcher l’ouverture de fichiers, tuer des processus ou refuser des allocations.

1 Like
13

QEMU ne me semble pas une option vu la charge CPU induite que ça génère.

1 Like