Fuite mémoire sur Duniter-ts 1.6.23 ?

Après environ 3 semaines de fonctionnement en intensif (grosse activité ws2p public + pow), mon seul nœud membre avec ws2p public viens de s’arrêter pour cause de manque d’espace mémoire :

2018-04-18T23:22:49+02:00 - info: ✘ CERT 4CwKZpNQhFx519cELDhs4364ZWDdcKeK2LnsmbF51ewA Already up-to-date
2018-04-18T23:22:49+02:00 - info: ⬇ CERT 5nHhk6wwHELKPn5zvUYjzK9gN1iT214udKyXg5PFazq3 block#107743 -> Miska
2018-04-18T23:22:49+02:00 - info: ✘ CERT 5nHhk6wwHELKPn5zvUYjzK9gN1iT214udKyXg5PFazq3 Already up-to-date
2018-04-18T23:22:49+02:00 - info: ⬇ CERT 5dzkzedBWdeqTFCaD7AkKPMPusfRUL1XyFNJWWGYQ9f1 block#110719 -> ArthurLutz

<--- Last few GCs --->

[24608:0x39be3a0] 1814582485 ms: Mark-sweep 1283.3 (1458.2) -> 1283.2 (1460.2) MB, 2966.8 / 2.8 ms  allocation failure GC in old space requested
[24608:0x39be3a0] 1814584457 ms: Mark-sweep 1283.2 (1460.2) -> 1283.2 (1427.2) MB, 1972.0 / 3.3 ms  last resort GC in old space requested
[24608:0x39be3a0] 1814586515 ms: Mark-sweep 1283.2 (1427.2) -> 1283.2 (1427.2) MB, 2057.7 / 3.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0x6cfc80225501 <JSObject>
    1: writeOrBuffer(aka writeOrBuffer) [_stream_writable.js:~359] [pc=0x6cfc84ca1b95](this=0x6cfc804022d1 <undefined>,stream=0x6cfbb2425d51 <DeflateRaw map = 0x6cfc7275ceb1>,state=0x6cfbb2425ec1 <WritableState map = 0x6cfc80142db9>,isBuf=0x6cfc804023e1 <false>,chunk=0x6cfbb897d3f1 <Very long string[919203]>,encoding=0x6cfc80234ea9 <String[4]: utf8>,cb=0x6cfc7363fab9 <JSFunction nop (sfi = 0x6cf...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/opt/duniter//node/bin/node]
 2: 0x11f155c [/opt/duniter//node/bin/node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [/opt/duniter//node/bin/node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/opt/duniter//node/bin/node]
 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/opt/duniter//node/bin/node]
 6: v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [/opt/duniter//node/bin/node]
 7: v8::internal::String::Flatten(v8::internal::Handle<v8::internal::String>, v8::internal::PretenureFlag) [/opt/duniter//node/bin/node]
 8: v8::String::WriteUtf8(char*, int, int*, int) const [/opt/duniter//node/bin/node]
 9: node::StringBytes::Write(v8::Isolate*, char*, unsigned long, v8::Local<v8::Value>, node::encoding, int*) [/opt/duniter//node/bin/node]
10: node::Buffer::New(v8::Isolate*, v8::Local<v8::String>, node::encoding) [/opt/duniter//node/bin/node]
11: 0x1211364 [/opt/duniter//node/bin/node]
12: 0x6cfc80b87247
/usr/bin/duniter : ligne 15 : 24608 Abandon                 $NODE "$DUNITER_DIR/bin/duniter" "$@"

On voit d’ailleurs clairement l’espace mémoire pris par Duniter grossir (en vert) sur le graphe mensuel de munin :

fuite_memoire_duniter_ts

Peut être que l’augmentation fulgurante de la taille du réseau Duniter il y a une dizaine de jours a provoquer une intensification de l’activité de WS2P et donc augmenter la quantité de RAM nécessaire, mais tout de même 8Go devraient être suffisants :thinking:

Cela étant cette fuite (si c’en est une ?) n’est pas vraiment gênante, dans la pratique il est rare de laisser un nœud tourner non-stop aussi longtemps. Et ça me semble coton a corriger :laughing:

Coton à corriger, je veux bien, rare de faire tourner un noeud aussi longtemps… Pourquoi donc ?
Tout les noeud qui tourne sur des serveurs ont des chances de tourner H24 7/7 non ?

Duniter ne devrait pas utiliser plus de 500Mo sur un serveur, en cible. À la limite 1Go, ça resterait acceptable bien que très élevé.

Je veux dire : Duniter ne fait en réalité pas grand-chose en termes de manipulation de données, et le volume est encore très faible avec 1000 membres.

Il faudra trouver la cause de cette fuite, ça fera partie des sujets à aborder durant les RML11.

4 Likes