-
Notifications
You must be signed in to change notification settings - Fork 37.7k
log mempool loading progress #29227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
log mempool loading progress #29227
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. |
Concept ACK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review ACK 6c3ca0c
I have not executed the code but I spent time reviewing the loop and the conditions within it, using your example provided in the PR description (401 txs). Looks good to me
Concept ACK |
Concept ACK. I remember being surprised in the past that >5 minutes after starting up the node, my mempool was still loading. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 6c3ca0c
Reviewed the code and tested locally (mempool with ~26k txs), LGTM. Probably less important, but I think it would be nice to have more verbose logging also for dumping the mempool. I've heard sentences like "I wonder why Bitcoin Core takes so long to shutdown sometimes?" repeatedly from users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code review ACK 6c3ca0c
Log at the top before incrementing so that this log isn't printed when there's only 1 tx.
6c3ca0c
to
eb78ea4
Compare
CI failure is unrelated, #29234 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK eb78ea4
It will be nice to also log how many transactions were dumped not just unbroadcast set
diff --git a/src/kernel/mempool_persist.cpp b/src/kernel/mempool_persist.cpp
index cae4b04bf65..404f23b21a9 100644
--- a/src/kernel/mempool_persist.cpp
+++ b/src/kernel/mempool_persist.cpp
@@ -194,7 +194,6 @@ bool DumpMempool(const CTxMemPool& pool, const fs::path& dump_path, FopenFn mock
file << mapDeltas;
- LogPrintf("Writing %d unbroadcast transactions to disk.\n", unbroadcast_txids.size());
file << unbroadcast_txids;
if (!skip_file_commit && !FileCommit(file.Get()))
@@ -203,6 +202,7 @@ bool DumpMempool(const CTxMemPool& pool, const fs::path& dump_path, FopenFn mock
if (!RenameOver(dump_path + ".new", dump_path)) {
throw std::runtime_error("Rename failed");
}
+ LogInfo("Written %d mempool transactions to disk, %d are unbroadcasted transactions.\n", vinfo.size(
), unbroadcast_txids.size());
auto last = SteadyClock::now();
LogPrintf("Dumped mempool: %gs to copy, %gs to dump\n",
Shutdown logs will be like
2024-01-12T14:43:49Z Shutdown: In progress...
2024-01-12T14:43:49Z torcontrol thread exit
2024-01-12T14:43:49Z addcon thread exit
2024-01-12T14:43:49Z opencon thread exit
2024-01-12T14:43:49Z net thread exit
2024-01-12T14:43:49Z msghand thread exit
2024-01-12T14:43:49Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat started
2024-01-12T14:43:49Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)
2024-01-12T14:43:49Z scheduler thread exit
2024-01-12T14:43:49Z Written 51 mempool transactions to disk, 51 are unbroadcasted transactions.
2024-01-12T14:43:49Z Dumped mempool: 3.0667e-05s to copy, 0.00451417s to dump
while (txns_tried < total_txns_to_load) { | ||
const int percentage_done(100.0 * txns_tried / total_txns_to_load); | ||
if (next_tenth_to_report < percentage_done / 10) { | ||
LogInfo("Progress loading mempool transactions from disk: %d%% (tried %u, %u remaining)\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit
LogInfo("Progress loading mempool transactions from disk: %d%% (tried %u, %u remaining)\n", | |
LogInfo("Progress loading mempool transactions from disk: %d%% completed (tried %u txs, %u txs remaining)\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better if this information were also exposed to the gui? Perhaps something along the lines of:
auto& cm = active_chainstate.m_chainman;
if (!cm.IsInitialBlockDownload()) {
cm.GetNotifications().progress("Loading mempool...", percentage_done, false);
}
would make sense? (completely untested)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code review ACK eb78ea4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-ACK eb78ea4
Concept ACK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested ACK eb78ea4
Concept ACK eb78ea4 |
I don't think that's due to dumping the mempool, but rather spinning on locks elsewhere in the code. I've seen very slow shutdowns myself, but been unable to nail it down precisely. |
Leaving gui notifications (#29227 (comment)) and dumping logs (#29227 (review)) up for grabs |
Log at the top before incrementing so that this log isn't printed when there's only 1 tx. Github-Pull: bitcoin#29227 Rebased-From: eb78ea4
26.x backport in #29209 |
Log at the top before incrementing so that this log isn't printed when there's only 1 tx. Github-Pull: bitcoin#29227 Rebased-From: eb78ea4
Log at the top before incrementing so that this log isn't printed when there's only 1 tx. Github-Pull: bitcoin#29227 Rebased-From: eb78ea4
11f3a7e Use hardened runtime on macOS release builds. (Mark Friedenbach) ac1b9a5 [test] import descriptor wallet with reorged parent + IsFromMe child in mempool (glozow) ecb8ebc [test] rescan legacy wallet with reorged parent + IsFromMe child in mempool (Gloria Zhao) 438ac29 snapshots: don't core dump when running -checkblockindex after `loadtxoutset` (Mark Friedenbach) 7ec3455 [log] mempool loading (glozow) fe0f8fe net: create I2P sessions with both ECIES-X25519 and ElGamal encryption (Jon Atack) fc62271 [refactor] Add helper for iterating through mempool entries (stickies-v) Pull request description: Backports for 26.x. Includes: - 453b481 from #28391 - #29179 - #29200 - #29227 - #28791 - #29127 ACKs for top commit: stickies-v: ACK 11f3a7e Tree-SHA512: 20ef871ec768f2328056d83f958e595b36ae9b8baa8a6e8b0e1f02c3df4b16965a8e05dcb4323afbcc9ecc4bdde10931232512022c39ee7e12baf9795bf25bf1
…disk 4d5b557 log: renamed disk to file so wording was more accurate (kevkevin) b9f04be mempool: Log added for dumping mempool transactions to disk (kevkevin) Pull request description: Sometimes when shutting off bitcoind it can take a while to dump the mempool transaction onto the disk so this change adds additional logging to the `DumpMempool` method in `kernel/mempool_persist.cpp` Motivated by #29227 this change - adds a single new line for the amount of transactions being dumped and the amount of memory being dumped to file This is in response to #29227 (comment) The logs will now look like this ``` 2024-02-09T23:41:52Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.02s) 2024-02-09T23:41:52Z scheduler thread exit 2024-02-09T23:41:52Z Writing 29 mempool transactions to file... 2024-02-09T23:41:52Z Writing 0 unbroadcast transactions to file. 2024-02-09T23:41:52Z Dumped mempool: 0.000s to copy, 0.022s to dump, 0.015 MB dumped to file 2024-02-09T23:41:52Z Flushed fee estimates to fee_estimates.dat. 2024-02-09T23:41:53Z Shutdown: done ``` ACKs for top commit: maflcko: cr-ACK 4d5b557 glozow: reACK 4d5b557 Tree-SHA512: 049191e140d00c1ea57debe0138f1c9eb0f9bb0ef8138e2568e6d89e64f45a5d5853ce3b9cc0b28566aab97555b47ddfb0f9199fc8cea6b81e53f50592d5ae6a
Motivated by #29193. Currently, we only log something (non-debug) when we fail to load the file and at the end of importing all the transactions. That means it's hard to tell what's happening if it's taking a long time to load.
This PR adds a maximum of 10 new unconditional log lines:
If there are lots of transactions in the mempool, the logs will look like this:
If there are 0 or 1 transactions, progress logs aren't printed.