Skip to content

Conversation

@jschaul
Copy link
Member

@jschaul jschaul commented Apr 17, 2025

This PR changes the way assets are uploaded to S3.
This PR makes use of multi-part uploads API via the amazonka-s3-streaming library.

  • Question: Should we increase the default memory limits? The library sends in chunks of 6 MB (not possible to decrease). For comparison, we were using chunks of 128 KB for the body before.

Checklist

  • Add a new entry in an appropriate subdirectory of changelog.d
  • Read and follow the PR guidelines

Context:

cargohold needs to be compatible with StorageGRID.
Without this PR cargohold receives 400 Bad request when uploading. It might be related to this comment:
: https://docs.netapp.com/us-en/storagegrid/s3/s3-rest-api-supported-operations-and-limitations.html#common-request-headers

Switching to multi-part uploads seems to fix the problem.

See also https://wearezeta.atlassian.net/browse/WPB-17236

@zebot zebot added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label Apr 17, 2025
@smatting smatting changed the title WIP cargohold stackit cargohold: use multi-part uploads to S3 Apr 23, 2025
@smatting smatting marked this pull request as ready for review April 23, 2025 12:59
@smatting smatting requested review from a team as code owners April 23, 2025 12:59
@smatting
Copy link
Contributor

I wasn't able to figure out the maximum number of lightweight threads the warp server will spawn. This could help to inform a good setting for the memory cargohold might need.

@akshaymankar
Copy link
Member

I wasn't able to figure out the maximum number of lightweight threads the warp server will spawn. This could help to inform a good setting for the memory cargohold might need.

I think there is no maximum. Perhaps we should just use net.connections metrics from production to decide this?

Copy link
Member

@akshaymankar akshaymankar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!
Feel free to tweak the default memory requests and limits separately.

@jschaul jschaul merged commit b5ae846 into develop Apr 24, 2025
8 checks passed
@jschaul jschaul deleted the cargohold-no-steaming branch April 24, 2025 12:41
@jschaul
Copy link
Member Author

jschaul commented Apr 24, 2025

It seems our concurrent uploads per second are not very high; so current limits should be okay. We should monitor and increase if we discover OOMkills.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants