btcd performance degredation over time (getwork/getblocktemplate)

[toddfries]

See:

http://p2pool0.fdh.bz:9332/static/graphs.html?Week#getwork_latency

or

http://p2pool0.fdh.bz:9332/static/graphs.html?Day#getwork_latency

Over time, btcd latency increases from near 0s delay response time up to 20s and beyond. It's a nearly linear degredation, and I am actively exploring automating the restart of btcd to minimize impact on p2pool income.

I'll provide more details of my setup below, but stock current git code after the latest db switcheroo speedup, 6gb mem virtual machine inside a 16gb mem physcal machine running proxmix with a dcr node in another virtual machine (not a heavy hitting compeditor!) as the only other node on the box.

Feel free to ask for performance bits or any other details to help track this down. Thanks!

[davecgh]

We discussed this a bit in the IRC channel and the most likely cause is the fact the time it takes to build is block template is currently almost completely linear with the number of transactions there are in the memory pool.

There are several optimizations that can be made to the template building code. One of the things we have discussed before is building the templates in the background and atomically replace a pointer to the most recent block template whenever they get built. The getblocktemplate RPC would then just need to return that already constructed template.