I fixed it - my bad
Topic: Has your mempool sorting also been slow recently? (Read 257 times)
OK, thank you everybody.
I fixed it - my bad
I fixed it - my bad
Thanks. Must be something i screwed up with porting the code.
Perhaps you could help ma to figure it out.
At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:
It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.
It's built by AddPackageTxs which calls AddToBlock repeatedly. It's used if AddPackageTxs is called multiple times. Perhaps you could help ma to figure it out.
At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:
Code:
UpdatePackagesForAdded(inBlock, mapModifiedTx);
It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.
Thanks. Must be something i screwed up with porting the code.
Perhaps you could help ma to figure it out.
At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:
It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.
Please check you are porting the optimized version of both addPackageTxs and UpdatePackagesForAdded as it has been proposed and merged after pull request #9959 Perhaps you could help ma to figure it out.
At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:
Code:
UpdatePackagesForAdded(inBlock, mapModifiedTx);
It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.
Thanks. Must be something i screwed up with porting the code.
Perhaps you could help ma to figure it out.
At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:
It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.
Perhaps you could help ma to figure it out.
At a beginning of the function BlockAssembler::addPackageTxs (in src/miner.cpp) it does:
Code:
UpdatePackagesForAdded(inBlock, mapModifiedTx);
It seems that at this point the inBlock variable shall contain a set of transactions.
Where is this set built? I can't find that place in the source code.
Nope. getblocktemplate seems to be pretty fast. Dunno how long it used to take, but it's not currently a noticeable time to execute.
Code:
> time src/bitcoin-cli getblocktemplate '{"rules":["segwit"]}' > /dev/null
________________________________________________________
Executed in 39.05 millis fish external
usr time 7.65 millis 272.00 micros 7.38 millis
sys time 0.02 millis 24.00 micros 0.00 millis
So booted and synced my "lottery pool" yesterday and had a miner pointing at it all night till just now.
I am looking at all the utilization monitoring I saw no unusual spikes and no unusual activity.
I also have a mempool.space explorer sitting on the same VM as the pool & node and it was performing fine also.
So for this limited test it *seems* to point to something on your end OR something I am just not seeing here.
-Dave
I am looking at all the utilization monitoring I saw no unusual spikes and no unusual activity.
I also have a mempool.space explorer sitting on the same VM as the pool & node and it was performing fine also.
So for this limited test it *seems* to point to something on your end OR something I am just not seeing here.
-Dave
I'm not sure if it help, but my node's RAM, CPU and HDD I/O usage remains low on default configuration. I don't experience lag when i open multiple application at same time.
You might be better off posting this as an issue to github. For things like this you will probably get a bit more support.
With that being said, I am spinning up the VM that I have a pool on with a node, will let you know if I see anything when it finishes syncing. It's been off for a few weeks.
-Dave
With that being said, I am spinning up the VM that I have a pool on with a node, will let you know if I see anything when it finishes syncing. It's been off for a few weeks.
-Dave
What I found so far.
I cant really find the relevant code in the current bitcoin core sources, but the code I am using myself was once based on what core was doing (at least that was the idea).
So the first stage of sorting is finding the packages.
A package is a child tx with all its (unconfirmed) parent txs.
What I am seeing now is mempool of 5851 transactions.
This comes down to 4142 packages...
But inside these 4142 packages there is a total of 5773388 parent txs.
I'd say that it is quite a lot and it takes my PC over one second to build the package list.
Either my function to look for the packages has suddenly turned out to be screwed up, or the recent content of the mempool has been deliberately engineered to cause such a behavior.
If it is the second, then bitcoin core (at least the mining nodes) might be suffering from it as well.
Someone please look into this.
I cant really find the relevant code in the current bitcoin core sources, but the code I am using myself was once based on what core was doing (at least that was the idea).
So the first stage of sorting is finding the packages.
A package is a child tx with all its (unconfirmed) parent txs.
What I am seeing now is mempool of 5851 transactions.
This comes down to 4142 packages...
But inside these 4142 packages there is a total of 5773388 parent txs.
I'd say that it is quite a lot and it takes my PC over one second to build the package list.
Either my function to look for the packages has suddenly turned out to be screwed up, or the recent content of the mempool has been deliberately engineered to cause such a behavior.
If it is the second, then bitcoin core (at least the mining nodes) might be suffering from it as well.
Someone please look into this.
I'm not sure if the sorting function is actually used if you're not mining on the node.
Eventually, it can be called when you exceed the mempool size limit, but that would not be a case recently.
Eventually, it can be called when you exceed the mempool size limit, but that would not be a case recently.
I have not noticed a change on any of the nodes I pay attention to.
There are a few low power ones I run that are RPi based that I play with but do not really do much with that might be having an issue.
I just checked one of the RPi now when I saw this post but the mempool had just cleared so nothing to report.
If i have time during the day I'll remote home and see if anything is up.
-Dave
There are a few low power ones I run that are RPi based that I play with but do not really do much with that might be having an issue.
I just checked one of the RPi now when I saw this post but the mempool had just cleared so nothing to report.
If i have time during the day I'll remote home and see if anything is up.
-Dave
Is it just a problem with my implementation, or is there some sort of attack going on, exploiting the Child-Pays-For-Parent sorting algorithm?
The sorting (of the existing mempool) takes far too long.
The sorting (of the existing mempool) takes far too long.
Jump to: