RPC Calls are very slow to respond #385
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#385
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The wallet rpc calls are very slow to respond
This takes 12 seconds to get executed
The wallet is almost always using 100% of a CPU core.
Running v17.3.2
v17.3.2 uses about 5GB of RAM after running a full sync. Restarting it will reduce the RAM usage (for a while). Do you have that much free RAM? You might be memory swapping.
The "-getinfo" call is slow. I don't know why other than it's built from several other calls. If you call getblockchaininfo or getwalletinfo or getnetworkinfo -- those individual calls should go faster.
All was extremely slow, this wallet had many txs and I had to delete the wallet and use a brand new one
Thanks for clarifying that it's the wallet RPC calls that are slow. Please test it in v0.17.4.5 and report times for the wallet there.
This is to confirm that daemon behaviour is extremely slow. Most of time RPC calls take more than 10 seconds to return results.
Sometimes it recovers, but only for short period of time, then it is slow again.
Loading wallet itself takes 40mins. Reindexing super slow too.
We will not able to support it soon on mining pools if corrective actions are not taken.
@pinpins , are you managing many accounts in your wallet? Or does it just contain a large number of transactions? It's common for heavily-used lbrycrd wallet instances to require consolidation of transactions from time to time. Essentially, you send all the funds to a single address in a new wallet and discontinue use of the previous wallet. Would that meet your requirements or not? Perhaps some others could offer additional insight into their wallet management: tagging @tzarebczan , @nikooo777, @lyoshenka
Consider use 17.4.6 i've test some rpc calls
-getinfo
is instant, other can be slower but less than 10 sec. Also note run daemon with higher db cache./lbrycrdd -dbcache=8192
Well, we host mining pool and mostly mining LBRY blocks, regardless of wallet size and history there. I do believe getblocktemplate should be instant regardless.
Okay, so downgrading is essentially ok for mining pool?
Also starting up lbry daemon takes 40mins, mostly on loading block index status message
@pinpins did you try running your current version of lbrycrdd with -dbcache=8192?
It does improve performances by a lot.
If that is not sufficient then downgrading should be fine.
I have tried for last 12h, definately loading was super fast but getblocktemplate {"rules":["segwit"]} takes 20 seconds still
@pinpins , which version are you running? Are you using an HDD or SSD or NVMe storage device? I just tested on v19 latest and was seeing about a tenth of a second per call to
getblocktemplate
(on NVMe).Using NVMe storage. Well it works sometimes quickly, but most of the cases it takes more than 5-10 seconds.
Below sample for last 40 minutes
Tried to run 0.17.4.5, but seems no major improvement.
hello, any further clues on this issue?
Side note @pinpins:
I'm debugging the stratum part of https://github.com/LBRYFoundation/pool to understand the high reject rate. The message I see over and over in the log is
Looking at the
errno
of thesend()
-call indicatesBroken pipe
. I think I will have a closer look at what's happening behind the scenes in the daemon. Maybe the result can help to fix your problem too.