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 :
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 
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 