Fix unbounded buffering when one node has slower network #792
No reviewers
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#792
Loading…
Reference in a new issue
No description provided.
Delete branch "fix-buffering"
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?
Add mechanism to limit the number of blocks buffered in RAM as they await being sent to storage nodes. Backpressure is applied to the clients when the limit is reached. The size of this buffer can be controled using the config parameter
block_ram_buffer_max
Add metric
block_ram_buffer_free_kb
to visualize memory still available for buffers (when it drops to zero, backpressure is applied)Change the network scheduling algorithm to send requests one after the other, instead of least-attained-service that was equivalent to a round-robin and would cause all blocks to be buffered simultaneously
Related: #788
Fix buffering issues (fix #788)to Fix unbounded buffering when one node has slower network (fix #788)9613f9495e
to85f580cbde
Confirmed that this avoids unbounded memory usage growth inducing OOM kill on a test deployment when sending a single 8GB file to an S3 API server on localhost, which had to send to two other storage nodes, one a bit slower than the other.
With the default value of
block_ram_buffer_free_kb
(256MB), the RAM usage of Garage as measured by RssAnon is stable under 300MB during the transfer, and the overall speed of the transfer is correctly capped to the speed of the slowest internet link between nodes. Without the patch the API server received data faster than it could send back to storage nodes and RAM usage grew to 1GB, 2GB, 3GB, ... and provoked an OOM kill of the daemon.Fix unbounded buffering when one node has slower network (fix #788)to Fix unbounded buffering when one node has slower networkFix unbounded buffering when one node has slower networkto Fix unbounded buffering when one node has slower network (fix #788)Fix unbounded buffering when one node has slower network (fix #788)to Fix unbounded buffering when one node has slower network