Add storage.low_mem config parameter #461
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#461
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-node:fix/lowmem_config"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #428
Now this parameter prohibits parallel metabase resync only. In case of many shards and low memory available on machine it can lead to OOM.
I haven't specify this parameter in config example as it will be rarely used i think.
@ -79,0 +80,4 @@
if e.cfg.lowMem && e.anyShardRequiresRefill() {
concurrentLimit = 1
}
sem := make(chan struct{}, concurrentLimit)
Why don't we just use
errgroup
?fixed
e83612b6bc
toae04be3fa9
ae04be3fa9
to5bcf708766
@ -76,3 +77,3 @@
var wg sync.WaitGroup
var errCh = make(chan shardInitError, len(e.shards))
eg, _ := errgroup.WithContext(ctx)
why ignore the derived context? shouldn't it be used by
sh.Init(ctx)
below?eg.Go
doesn't return error, so there is no need to use derived ctx. Derived ctx needed in case of some goroutine returns error, then derived ctx will be cancelled.well, but that was my point, to stop further initialization if one of them failed already.
ok, fixed
Well, actually, no, this is a feature -- if ONE shard cannot be initialized, we just remove it and continue initialization for others. Adding context doesn't change it actually, because we sent an error to the channel.
However I am a bit concerned now:
From https://pkg.go.dev/golang.org/x/sync/errgroup#WithContext (cursive is mine):
And this context is passed to GC, have you checked it doesn't lead to problems?
May be indeed #461 (comment) was a mistake.
if that's the case then don't use
WithContext
in the first place? i.e. simplyvar eg errgroup.Group
. Otherwise it's kinda misleading.Thank you! Replace with var
5bcf708766
to209dcee921
209dcee921
toec828e0097
ec828e0097
toefa79a22cb