-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
logical segregation of blockstores + freecache-cached chain and state blockstores #4771
Conversation
4d38e94
to
3ef260f
Compare
c383524
to
fe01fb4
Compare
This commit introduces FreecacheCachingBlockstore, a caching-façade for blockstores. It can be mounted on any blockstore using blockstore.WrapFreecacheCache. We use a fork of freecache that supports zero-copy value access.
This commit introduces ChainBlockstore and StateBlockstore, two logical abstractions on top of the current monolith blockstore. Each of them is backed by a different cache configuration, that has been picked through experimentation, leading to ~70-80% hit ratios during catch-up sync. I believe these hit ratios to extrapolate to live sync. The ARC caches have been removed. The footprint of the new caches is 432MiB. The underlying store is exposed as BareMonolithBlockstore. This store is now used in external-facing components via ExposedBlockstore: Bitswap, Graphsync, and JSON-RPC. This increases security, such that external actors cannot influence in our caching decisions. This commit also removes the optionality of the Viewer interface on state and chain blockstores. The new type blockstore.LotusBlockstore is the union of Blockstore + Viewer, and is now required in most places.
c21da23
to
d0b5d66
Compare
7b42f33
to
587851a
Compare
lib/blockstore/blockstore.go
Outdated
// LotusBlockstore is a standard blockstore enhanced with a view operaiton | ||
// (zero-copy access to values), and potentially with cache management | ||
// operations, or others, in the future. | ||
type LotusBlockstore interface { | ||
Blockstore | ||
Viewer | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we drop the alias below, and call this Blockstore
? Would let us avoid all the renaming everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what I did initially, but I reverted because it causes ambiguity in those places that still take a standard Blockstore (e.g. Graphsync and others). We would end up with two blockstore.Blockstore
interfaces that are different because one embeds the other...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can still alias that blockstore here, just as something like BasicBlockstore
(to relay the fact that the non-viewer blockstore is not the one that should be used by default).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in 66336b9.
eae3b9a
to
4dadb11
Compare
4dadb11
to
672669e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first pass looks ok, but there are bound to be some bugz in this monster...
@raulk this has developed conflicts... |
@vyzo they're tiny and I believe unrelated to the work you're doing. Let's resolve them when we have something to merge. |
absorbed into #4992 |
Fixes #4752.
This PR segregates the monolithic blockstore into two logical blockstores: the chain and the state blockstore.
Currently they're backed by the same physical store, but the abstractions introduced here allow us to front the chain and the state blockstores by different caches, each tuned for the specific data access pattern of its nature. The also pave the way for upcoming physical segregation.
The caching is based on Freecache, a near LRU cache. Given our access patterns, pure LRU is estimated to behave better than ARC/2Q. We use a fork of Freecache (maintained by me) that enables zero-copy access to cached values. The total footprint of the caching layer is 416MiB.
The ARC cache is no longer used, and the deprecated
CachingBlockstore
has been removed.This PR also introduces a
LotusBlockstore
interface. It is the union of theBlockstore
andViewer
interfaces, and is required by the chain and state blockstores. This way, we remove the optionality ofViewer
and simplify the code.This PR also removes block size caching (Lotus never calls blockstore.GetSize).
Benchmark
Note that these comparisons put the cached version at a disadvantage, because the store is still light. As the store grows, the benefits of the cache are much higher.
Hit rate
Block validation times
Before
Average: 1470,861553784860558 ms (91% validated under 2000ms)
After
As you can see, the distribution has changed. Average: 1266,592261904761905ms (-14%) (95% validated under 2000ms).
GC/allocs stats
Before
After
TODO