search

BTCPrivate / BitcoinPrivate-legacy

Bitcoin Private is a Bitcoin and Zclassic fork which uses ZK-SNARK technology for privacy and fungibility.
Other
283 stars 132 forks source link

btcpd (daemon) very high cpu utilization #138

Closed animan9 closed 6 years ago

animan9 commented 6 years ago

This issue tracker is only for technical issues related to btcpd.

Describe the issue

Please provide a general summary of the issue you're experiencing

btcpd used with z-noamp mining pool. btcpd cpu utilization goes sky high upto 200% cpu or more, preventing other threads to run. This is causing errors below:

2018-03-06 23:09:21 [Pool] [btcprivate] (Thread 2) Could not parse rpc data from daemon instance 0 Request Data: {"method":"getblocksubsidy","params":[],"id":1520395761210} Reponse Data: Work queue depth exceeded 2018-03-06 23:09:21 [Pool] [btcprivate] (Thread 4) Could not parse rpc data from daemon instance 0 Request Data: {"method":"getblocksubsidy","params":[],"id":1520395761345} Reponse Data: Work queue depth exceeded

Can you reliably reproduce the issue?

Yes, see steps below. Seeing this behavior on two different systems with little to no miner load.

Not sure if something in z-noamp is causing this issue with btcpd.

I have experimented with tweaking rpcworkque in the config file. Setting to larger values, eg 512 delays when the errors received, but eventually the errors start up. When I set rpcworkque=1024, I did not see any errors, even though cpu utilization was high, but after a while the daemon crashed.

Doesn't look like workqueue size is the issue. It seems like btcpd is not letting anything else to run.

If so, please list the steps to reproduce below:

  1. Start btcpd daemon. Notice very low cpu usage once synced to network
  2. Start z-noamp. CPU utilization jumps sky high even with no miners connected. After a while miner spews errors shown above.

Expected behaviour

Tell us what should happen

Actual behaviour + errors

Tell us what happens instead including any noticable error output (any messages displayed on-screen when e.g. a crash occurred)

The version of Bitcoin Private you were using:

Run btpcd --version to find out Machine 1 Bitcoin Private Daemon version v1.0.10-1-9ee1d69 Machine 2 Bitcoin Private Daemon version v1.0.10-1-40a6652c

Machine specs:

Machine 1

Machine 2

Any extra information that might be useful in the debugging process.

This includes the relevant contents of ~/.btcprivate/debug.log. You can paste raw text, attach the file directly in the issue or link to the text via a pastebin type site. Please also include any non-standard things you did during compilation (extra flags, dependency version changes etc.) if applicable.

Do you have a back up of ~/.btcprivate directory and/or take a VM snapshot?

interbiznw commented 6 years ago

Z-nomp is using the daemon to send funds.. The funds in z-nomp go from T-address to Z-address back to the 3rd address in the config which is a T-address before the funds are then spent and sent to miners.

When z-nomp sends the command to send the daemon is shielding the transactions. The shielding process is where you are seeing btcpd max out cpu usage.. How many cores does this machine have?

@jc23424 @BlueSilver22 Can we confirm that this is just normal shielding behavior?

BlueSilver22 commented 6 years ago

He says this is occurring as soon as it finishes syncing and z-nomp turns on. I imagine with no mined funds, it should not be performing any shielded txns at that moment.

Has anyone else experienced this before? We have had plenty of issues related to z-nomp but this has not been one of them thus far.

animan9 commented 6 years ago

Thanks for looking into this.... I believe the excess loading is related to the default pool config settings in config.json. When I reduced the "blockRefreshInterval" from 500 (default) to 100, I was able to reduce the btcpd CPU load from 200% to around 5%, as displayed by "top" utility.

Note the config.json file is common for all coins. I am only running the btcp daemon.. I am not sure if this change will adversely affect interaction with other coin daemons.

Thanks.

BlueSilver22 commented 6 years ago

@animan9 care to make a pull request?