Skip to content

Evict blocks based on size #1766

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

Merged
merged 18 commits into from
Aug 1, 2023
Merged

Evict blocks based on size #1766

merged 18 commits into from
Aug 1, 2023

Conversation

StephenButtolph
Copy link
Contributor

@StephenButtolph StephenButtolph commented Jul 27, 2023

Why this should be merged

With sustained large blocks (like observed with the hypersdk), the existing block caches evict too slowly. This changes the eviction policy to be size based.

How this works

Switch the usage of cache.LRU to cache.SizedLRU

How this was tested

  • CI
  • HyperSDK CI
  • Fuji Canary
  • Mainnet Canary

@patrick-ogrady
Copy link
Contributor

This resolved this issue: ava-labs/hypersdk#303

@StephenButtolph StephenButtolph marked this pull request as ready for review July 27, 2023 21:17
@StephenButtolph StephenButtolph added this to the v1.10.6 milestone Jul 27, 2023
@StephenButtolph StephenButtolph added consensus This involves consensus vm This involves virtual machines sdk This involves SDK tooling or frameworks labels Jul 27, 2023
"github.com/ava-labs/avalanchego/utils/wrappers"
)

const nonVerifiedCacheSize = 128
const (
nonVerifiedCacheSize = 128 * units.MiB
Copy link
Contributor

@abi87 abi87 Jul 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StephenButtolph just to very I understand the issue here:
These hyper blocks are beefy (> 1MB !!??) and are quickly verified.
With item based cash they are kept in memory until other 128 blocks arrive, which is (much) more than hyperSDK need to verify them.
A size-based cache would saturate faster and keep them less in memory (still longer than needed to verify them).
Is this correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct. This cache specifically probably didn't have a problem... But some of the other caches (with thousands of blocks) were causing issues.

return len(bw.Bytes()) + 2*pointerOverhead
},
),
bytesToIDCache: &cache.LRU[string, ids.ID]{Size: config.BytesToIDCacheSize},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while we keep this cache item based, should we reduce its size? I don't expect it to make a big difference if we don't, but IIUC it'll hold infos much longer than expected now, given other caches are size based?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great 👁️. I had forgotten that we had block bytes as a key in a cache.

Copy link
Contributor

@abi87 abi87 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a few questions to make sure I understand the change

@StephenButtolph StephenButtolph changed the base branch from dev to add-key-size-cache July 31, 2023 16:50
Base automatically changed from add-key-size-cache to dev July 31, 2023 18:45
Copy link
Contributor

@patrick-ogrady patrick-ogrady left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one clarifying question

)

func cachedBlockSize(_ ids.ID, bw *BlockWrapper) int {
return ids.IDLen + len(bw.Bytes()) + 2*constants.PointerOverhead
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this 2x? 1x for inner block pointer and one for the pointer to the wrapper object?

Copy link
Contributor Author

@StephenButtolph StephenButtolph Aug 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1x for inner block pointer and one for the pointer to the wrapper object?

Correct - went through and made sure I was consistent (there was 1 case a tx wrapper wasn't being accounted for correctly)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May make sense to comment this but that's def a nit

@StephenButtolph StephenButtolph merged commit 6e97e33 into dev Aug 1, 2023
@StephenButtolph StephenButtolph deleted the test-block-size-caches branch August 1, 2023 01:14
@patrick-ogrady patrick-ogrady linked an issue Aug 1, 2023 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus This involves consensus sdk This involves SDK tooling or frameworks vm This involves virtual machines
Projects
No open projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Investigate Unbounded AvalancheGo Memory Usage
3 participants