-
Notifications
You must be signed in to change notification settings - Fork 36.2k
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
Mempool memory usage underutilized #8609
Comments
What reason do you have to believe that this isn't perfectly correct? |
I don't get it. What is the problem here? The mempool size is a maximum cap, it willuse less than that after e.g. a block comes in and transactions are removed from it. |
Also see #8610, which effectively reassigns the unused portion of the
mempool for use by the chainstate cache.
|
@laanwj you ask a question, and then close the issue the same day without giving me a chance to answer. Are issues only issues as long as you personally understand them? Look at the graph half-way through - there is still a minimum relay fee even though the memory utilization is almost zero. This is the issue - why limit the txs at all when the utilization is almost 0%? Would it not make more sense to continue storing txs and only increase the restrictive criteria once utilization gets close to being 100%? |
@rebroad One design goal of the limited mempool was to prevent relay of Consider the following scenario: a peer figures out what the lowest feerate This could be exploited by anyone who observes the network wide behaviour, To combat this:
As you can see, for all of these countermeasures, we need an effective |
Closing issues (in contrast to locking them) doesn't prevent anyone from answering. To keep a lid on the sheer number of issues open, I have to do the thankless job of closing issues that are not clear user problems, but fall into other categories like "I've noticed this curious behavior and have questions about it". As I've said to you many times this is an issue tracker not a Q&A site. This is also not the place to make other people do your research/investigation for you. |
@laanwj I do not see github being used to do other people research/investigation, but I understand that you perceive this. I do not understand why though. I think the root cause of this is ultimately lack of documentation. @sipa 's very detailed response, IMHO, ought to be incorporated into such documentation. There is the question of where this documentation ought to best be stored. My answer to that question would be github - with the documentation for the functionality of each pull request being stored against the pull request. Ideally the documentation ought to be submitted with the pull request itself, or in the code as comments, but when this isn't done, then at least, retrospectively might be a suitable alternative. Perhaps I am unaware of such documentation that already exists - if so, then the issue, IMHO, would be making it easier for people to find it. |
I agree that there is a lack of documentation. Usually the code is considered the documentation and it becomes clear how something works, but the design principles usually are hidden somewhere else. (Maybe not even publicly accessible) For the protocol and general bitcoin related concepts, we have the Bitcoin Improvement Proposals... For documenting internal logic, you suggested to use github issues and pull requests. I disagree, the design rationale for the internal logic should be placed in properly formatted doxygen comments above each class/method. (We have the problem, that those comments usually outdate very quickly because contributors "forget" to update the comments. Unfortunately I don't know of a way to enforce during review that comments need to be updated when the code is changed. Maybe only a maintainer for the specific module could keep it in mind? While not perfect, I still think that documentation should be part of the source code.) |
100% agreed. Also note that while it's easy to forget to update developer documentation that is part of the source code, it is even easier to forget to update "design documents" that live elsewhere. We actually have a few of those in Application user documentation should probably exist outside the source code, although it can exist as something that can be queried from the program itself. Like the RPC Protocol documentation should exist outside this repository as it is not specific to Bitcoin Core. Examples of this are the BIPs, as well as the excellent Developer Reference on bitcoin.org. |
@sipa why would anyone want to relay txs around the network with no intention of them getting into blocks? |
In this example the mempool memory usage went to pretty much zero before eventually becoming useful again.
NOTE: This symptom becomes less pronounced when maxmempool and dbcache are increased.
UPDATE: The problem seems to occur just as much on another node with maxmempool and dbcache doubled - just at different times, so it may not be related to these values.
The text was updated successfully, but these errors were encountered: