Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3027 +/- ##
==========================================
+ Coverage 58.62% 58.74% +0.12%
==========================================
Files 2099 2104 +5
Lines 173514 175077 +1563
==========================================
+ Hits 101716 102852 +1136
- Misses 62750 63139 +389
- Partials 9048 9086 +38
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
| } | ||
|
|
||
| return store | ||
| return store, nil |
There was a problem hiding this comment.
Instead of changing the interface to return an error, wouldn't it be easier to just panic inside this constructor? Is there any benefit to return the error if we failed to create the store?
There was a problem hiding this comment.
Converted back to a panic().
As a general pattern, I prefer to return errors when possible instead of using panic, except in cases where I'm just doing sanity/invariant testing. But this isn't something I feel strongly enough to argue about, so I don't mind switching this one back. 😜
sei-db/config/sc_config.go
Outdated
|
|
||
| // FlatKVConfig is the configuration for the FlatKV (EVM) backend | ||
| FlatKVConfig flatkv.Config | ||
| FlatKVConfig *flatkv.Config |
There was a problem hiding this comment.
Why do we need to make this a pointer?
There was a problem hiding this comment.
Reverted back to a direct reference.
No need to make this a pointer, except that I prefer pointer types for any struct that has more than one or two fields. It's unlikely that this is going to be a major performance factor in this case, so I don't mind using a direct reference if that's your preferred pattern.
| if err := scStore.CleanupCrashArtifacts(); err != nil { | ||
| panic(err) | ||
| } | ||
| if err := scStore.CleanupCrashArtifacts(); err != nil { |
There was a problem hiding this comment.
Duplicate CleanupCrashArtifacts call here, we should remove the one above?
There was a problem hiding this comment.
Removed duplicate call. This was probably happened when I merged upstream into my branch.
| return fmt.Errorf("failed to batch read old values: %w", err) | ||
| } | ||
|
|
||
| s.phaseTimer.SetPhase("apply_change_sets_prepare") |
There was a problem hiding this comment.
Duplicate code s.phaseTimer.SetPhase("apply_change_sets_prepare")
| ) | ||
|
|
||
| // Configuration for the PebbleDB database. | ||
| type PebbleDBConfig struct { |
There was a problem hiding this comment.
These configs are not specific to PebbleDB, instead, they are specific to flatkv, I think we should move them to flatkv instead of put them here, we could change the db engine in the future for flatkv, but these configs are universal to all db engines
There was a problem hiding this comment.
Extracted configuration.
| // The number of shards in the key-value cache. Must be a power of two and greater than 0. | ||
| CacheShardCount uint64 | ||
| // The size of pebbleDB's internal block cache, in bytes. | ||
| BlockCacheSize int |
There was a problem hiding this comment.
Would recommend remove this BlockCacheSize from the config, we can set a tuned default value for now, we can add it in the future if we are 100% sure we need a different specific value for each DB.
In any way, we are not going rely on the PebbleDB internal cache for read optimization, so would recommend maybe just set a default number
There was a problem hiding this comment.
Removed in this PR and set to previous default, but I'd like to discuss adding it back in a future.
The block cache still serves an important role in database performance. It's used by pebble to cache LSM blocks, and we can't just disable it.
The reason why I added this config was because I thought the default value of 0.5gb was way too large for unit tests, which I generally prefer to use very little resources. Eventually I'd like to run unit tests in parallel, that will be tricky if each FlatKV instance utilizes 2.5gb memory.
Although I haven't done so yet, I'd actually like to enable configuration of ALL pebbleDB settings (although we can give them sane defaults). Right now it's tricky to experiment with pebble configuration because it's all hard coded.
Perhaps good for a quick in-person discussion.
sei-db/db_engine/pebbledb/db.go
Outdated
| opts types.OpenOptions, | ||
| enableMetrics bool, | ||
| config *PebbleDBConfig, | ||
| comparer *pebble.Comparer, |
There was a problem hiding this comment.
Do we have to pass the comparer in? Under what scenario will we pass in a custom comparer?
There was a problem hiding this comment.
Removed comparer parameter.
sei-db/state_db/sc/flatkv/config.go
Outdated
| return fmt.Errorf("account db config is invalid: %w", c.AccountDBConfig.Validate()) | ||
| } | ||
| if c.CodeDBConfig.Validate() != nil { | ||
| return fmt.Errorf("code db config is invalid: %w", c.CodeDBConfig.Validate()) |
There was a problem hiding this comment.
Nit: We shouldn't need to call Validate() twice here
| return fmt.Errorf("metadata db config is invalid: %w", c.MetadataDBConfig.Validate()) | ||
| } | ||
|
|
||
| if c.ReaderThreadsPerCore < 0 { |
There was a problem hiding this comment.
If ReaderThreadsPerCore == 0, and ReaderConstantThreadCount == 0, it will create a pool with 0 workers, causing deadlock issue?
There was a problem hiding this comment.
Good point. I've updated the pool constructor to more elegantly handle this case:
if workers <= 0 {
workers = 1
}
| if c.DataDir == "" { | ||
| return fmt.Errorf("data dir is required") | ||
| } | ||
| if c.CacheSize > 0 && (c.CacheShardCount&(c.CacheShardCount-1)) != 0 { |
There was a problem hiding this comment.
Shall we also validate and make sure CacheShardCount > 0?
There was a problem hiding this comment.
Good point. Validation added.
|
One blocker comment: I think we should decouple cache from db_engine as much as possible, which allows FlatKV to switch different db_engine easily without reimplmenting the cache for each engine in the future |
Describe your changes and provide context
Add a caching layer to FlatKV, more than doubling performance in cryptosim benchmarks.
Testing performed to validate your change
Unit tests, ran benchmark over several days.