bitcoin-qt slow to shut down after recent commits #1012

issue dooglus opened this issue on March 29, 2012

dooglus commented at 8:50 PM on March 29, 2012: contributor
After #1007 and #1010, bitcoin-qt is now taking around 25 seconds to quit cleanly. It seems to be writing a whole new copy of the blockchain.

I added code to time the flushes that happen in db.h and saw that it's taking 24s to flush the blockindex now:
```
addr.dat flush
addr.dat flush done in 127ms
blkindex.dat refcount=0
blkindex.dat flush
UPNP_DeletePortMapping() returned : 0
ThreadMapPort exiting
connection timeout
ThreadOpenConnections exiting
blkindex.dat flush done in 23975ms
```
I'm not sure which commit introduced this slowdown. rc1 quits in 12s for me. I'll find out and report back.

Update: 89516bd4e ("Speed up block downloading") is the commit that made the shutdown time double. If I comment out just the line that says:
```
dbenv.set_cachesize(nDbCache / 1024, (nDbCache % 1024)*1048576, 1);
```
then the shutdown speed goes back to 12s.

To see this effect more strongly, try running "bitcoin-qt -dbcache=250" then quitting immediately. The window disappears straight away, but the process thrashes the hard drive for over 3 minutes before shutting down. Maybe that's just the cost of using a disk cache though.
sipa commented at 11:45 PM on March 29, 2012: member

Yes, this is a known issue. It should only be present during or shortly after the initial sync though. I'm not sure how serious it is, but maybe we do need a progress bar with "cleaning up" instead of no GUI at all.
dooglus commented at 11:47 PM on March 29, 2012: contributor

This is happening for me with a fully synced blockchain. Definitely not any time close to the initial sync.

It even happens if I arrange for the client to have 0 peers (I use -connect=0.0.0.0 -nolisten, but there's probably a cleaner way).
gavinandresen commented at 3:04 PM on March 30, 2012: contributor

Not a showstopper in my opinion.

GUI for "cleaning up/shutting down" is a great idea, as is optimizing shutdown time in general.
dooglus commented at 9:10 PM on March 30, 2012: contributor

The only issue I can see is that people might think that because the window has closed that the client has closed, and so it's a safe time to shutdown, or backup the .bitcoin directory, when in fact it's probably a really bad time to do that, since there is still a lot of disk activity.
sipa commented at 10:47 AM on March 31, 2012: member

Agree.
laanwj commented at 5:50 AM on April 3, 2012: member
Right, the UI should have a shutdown state:
- Show a simple window with "Bitcoin is shutting down, do not turn off your computer until this message goes away" or similar
- Grey out the bitcoin icon in tray
Edit: The practical problem here I think is that Shutdown() calls exit() directly, so currently Qt has to be cleaned up before it is called, as it has no chance to do so later on.
Diapolo commented at 8:22 AM on April 3, 2012: none

Yes, the GUI should be the last component that is shutdown, so that we can display the progress infos.
rebroad commented at 1:27 AM on April 12, 2012: contributor

Since the dbenv.set_cachesize line was added, my bitcoin-qt takes around 6 minutes to close....
dooglus commented at 3:45 AM on April 12, 2012: contributor

@rebroad Do you have the blockchain downloaded?

I think it's known that shutting down can take a long time if you've recently been syncing the blockchain.

The bug I was reporting here is that the shutdown time has doubled even if the blockchain has been synced for months.
Diapolo commented at 6:16 AM on May 2, 2012: none

Is this still a problem with the new fast-shutdown (detachdb) enabled?
dooglus commented at 6:49 AM on May 2, 2012: contributor

I'll try it.

"-detachdb Detach block and address databases. Increases shutdown time (default: 0)"

That makes it sound like detachdb gives slower shutdown, not faster.

Where's the misunderstanding?
Diapolo commented at 6:51 AM on May 2, 2012: none

-detachdb is -detachdb=1, whereas the default is -detachdb=0, which is the fast shutdown I had a hard time understanding this, too :D.
dooglus commented at 6:56 AM on May 2, 2012: contributor

Without -detachdb it takes about 2s to close, and with -detachdb it takes about 18s. Both better than the 24s in the initial report.
Diapolo commented at 7:02 AM on May 2, 2012: none

@sipa Is there anything more planned or is 2s considered fine (which I think is okay).
laanwj commented at 7:14 AM on May 2, 2012: member

This can be considered solved, -detachdb is off by default, only enable it if you really need to. Detaching the database is slow and only important if you want to copy block data files around manually.

Closing the issue...
laanwj closed this on May 2, 2012
nreal2 commented at 9:53 PM on October 4, 2014: none

Yep and because of this slow shtudown thats invisible ive managed to get in situations to wait for hours for bitcoin workin again -- validating everything.. Switched a setting in conf, shutdown and tried to start too soon because i didnt know this - it corrupts blocks or something ;( I tought it was ssd disk that caused this hours rescan and switched to another ssd and same thing... Good to know that its not really down when the gui goes away. 0.9.2.1 0.9.3.0
suprnurd referenced this in commit cefc13fc79 on Dec 5, 2017
ptschip referenced this in commit 92f2ba4875 on Apr 5, 2018
lateminer referenced this in commit 0d05b5381d on Oct 30, 2019
MarcoFalke locked this on Sep 8, 2021