elementsd shutdown seems unnecessarily slow for long-running nodes
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
Direzione di ricerca
Inizia individuando il percorso di arresto che scarica manualmente l’indice dei blocchi e dealloca le relative voci, quindi confrontalo con il comportamento all’uscita del processo. Riproduci, se possibile, un arresto dopo un node in esecuzione da molto tempo e analizza i casi di test che creano e distruggono più indici dei blocchi. Il lavoro è completo quando evita il lavoro di arresto non necessario preservando al contempo l’eliminazione pulita nei casi in cui i test la richiedono.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I'm curious if other people are finding that elementsd shutdown takes forever when the node has been running for a very long time, or if this is somehow unique to my machine. It's possible this issue is somehow specific to mac or non-linux platforms; it's also possible it's been made worse by my memory-reducing fix.
What appears to be happening: during shutdown we manually unload the block index, and deallocate the entries, one at a time. This seems basically pointless -- all we're doing is manually freeing memory that will be freed anyway when the process exits. This does not seem to be slow if we've just started, but takes forever when run on a process that's been around for a long time. What I suspect is happening is that the block index has been paged out to disk, and in clearing it we're paging it in, a bit at a time, as we access the entries in random order. Even at SSD speeds, paging in multiple gigabytes using random reads is going to take ages.
(The more problematic possibility is some kind of leak, but I don't see the process having particularly excessive memory usage -- any more than usual -- so I don't think this is it.)
If possible, it would be nice to stop wasting all this effort on shutdown. Assuming it's in fact wasted, one possible catch is the use of the same codepaths in test cases -- we may still need to cleanly delete objects there, if we have to create and destroy multiple block indices before ending the process.
- Lingua principale
- C++
- Stelle
- 1.2k
- Fork
- 418
- Merge medio
- 1g 12h
- PR unite (30g)
- 13
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ElementsProject/elements
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 58/100
ElementsProject/elements#1555 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
ElementsProject/elements#1521 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 32/100
ElementsProject/elements#1516 · 5 commenti ·
-
Compilation error on WSL Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
ElementsProject/elements#1502 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 38/100
ElementsProject/elements#1500 · 2 commenti ·
Tutte le issue di ElementsProject/elements
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
ros2/message_filters#338 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
subsurface/subsurface#4984 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
flutter-webrtc/flutter-webrtc#2206 ·
-
litertlm-android AAR ships no consumer ProGuard rules → "mid == null" SIGABRT in minified apps Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
google-ai-edge/LiteRT-LM#3739 ·