indexserver: reduce defaults for compound shards #850
Conversation
zoekt-merge-index can OOM on instances with <=4GB mem. Hence we adjust the defaults. Larger instances can set the ENVs to higher values. Test plan: N/A
| @@ -1264,8 +1264,8 @@ func (rc *rootConfig) registerRootFlags(fs *flag.FlagSet) { | |||
| fs.BoolVar(&rc.disableShardMerging, "shard_merging", getEnvWithDefaultBool("SRC_DISABLE_SHARD_MERGING", false), "disable shard merging") | |||
| fs.DurationVar(&rc.vacuumInterval, "vacuum_interval", getEnvWithDefaultDuration("SRC_VACUUM_INTERVAL", 24*time.Hour), "run vacuum this often") | |||
| fs.DurationVar(&rc.mergeInterval, "merge_interval", getEnvWithDefaultDuration("SRC_MERGE_INTERVAL", 8*time.Hour), "run merge this often") | |||
| fs.Int64Var(&rc.targetSize, "merge_target_size", getEnvWithDefaultInt64("SRC_MERGE_TARGET_SIZE", 2000), "the target size of compound shards in MiB") | |||
| fs.Int64Var(&rc.minSize, "merge_min_size", getEnvWithDefaultInt64("SRC_MERGE_MIN_SIZE", 1800), "the minimum size of a compound shard in MiB") | |||
| fs.Int64Var(&rc.targetSize, "merge_target_size", getEnvWithDefaultInt64("SRC_MERGE_TARGET_SIZE", 1000), "the target size of compound shards in MiB") | |||
There was a problem hiding this comment.
@stefanhengl very late question here: why is the limit for compound shards still so much higher than our default shard size limit of 100MB?
There was a problem hiding this comment.
The purpose of compound shards is to amortize some of the constant costs we pay per shard (match tree construction, trigrams in memory). The bigger the compound shard the better. The reason is that, for big compound shards, we already have most trigrams in memory, so adding another repo to it comes for free. There is a graph in this blog post that shows the separation between N simple shards and 1 compound shard.
The size of the compound shard is only limited by memory and the supported max file size.
There was a problem hiding this comment.
It is more performant to search a simple shard though. That's why we only put rarely updated small repos into compound shards. We use size and update frequency as a very rough proxy for "less important".
There was a problem hiding this comment.
I see, thanks for the background context! It would be nice if we had the same "max shard size" limit everywhere -- it's an easier mental model, so we know both index and merge should be bounded by roughly the same memory. But I'm guessing we tested this when we developed shard merging and found that the larger shards are beneficial.
Relates to SPLF-615
zoekt-merge-index can OOM on indexer instances with <=4GB MEM. Hence we lower the defaults. Larger instances should set the ENVs to higher values.
Test plan:
N/A