Increase default emerge queue limits and limit enqueue requests for active blocks. #10616
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Partially related to #10597
The visual view cone of a player could be up to 2400 blocks.
The current emerge queue limits are 64 for disk reads, 64 for block generate, and 512 for a server in total.
Thus the queues would full over and over before the blocks have been loaded.
Even before #10597 these were quite low. This PR doubles these values - I would consider even that very conservative (I have certainly set mine much higher, but we have to start somewhere).
Note that these settings only increase the server's ability to queue requests, and hence to pace its work better.
I will renew my call to please reduce the "insane" number of config options.
@paramat Do need both a disk and generate queue limit (again this is not a work limit, but a queue limit)? When would I set these differently?
Edit: In return block requests on behalf of ABMs are limited to 1/2 of the total (as is, ABM requests can starve out the loading of visible blocks)