Use cross-shard load information to limit the number of accepted receipts #9228
Labels
A-congestion
Work aimed at ensuring good system performance under congestion
Milestone
Comments
aborg-dev
added
the
A-congestion
near-bulldozer bot
pushed a commit
that referenced
this issue
Jul 27, 2023
…9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in #9228. Addresses: #8877
nikurt
pushed a commit
that referenced
this issue
Jul 28, 2023
…9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in #9228. Addresses: #8877
nikurt
pushed a commit
that referenced
this issue
Aug 24, 2023
…9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in #9228. Addresses: #8877
nikurt
pushed a commit
to nikurt/nearcore
that referenced
this issue
Aug 24, 2023
…ear#9222) This PR introduces a soft limit on the number of delayed receipts in each shard. The limit is around 10000 delayed receipts to make sure this is enough to saturate the chunk capacity even if receipts are very small. The largest number of delayed receipts that we've seen in the last 3 months is around 400 and it stays at 0 most of the time. In the future, we would be also using other signals like the size of delayed receipts, but this information will have to be first computed and stored in the chunk headers/trie store and will be done in near#9228. Addresses: near#8877
|
This work is superseded with near/NEPs#539. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a continuation of work from #8877 - after that work, the chunk producers will stop including transactions into a chunk if the local number/size of delayed receipts in the shard this above a threshold.
The number of delayed receipts still can grow unbounded in a multi-shard environment due to incoming receipts from other shards that might also be added to delayed receipts.
In order to deal with incoming receipts, we will introduce additional admission criteria for including transactions into a chunk, based on the capacity available in the shards that this transaction will send receipts to.
Tasks
The text was updated successfully, but these errors were encountered: