mirror of
https://github.com/go-gitea/gitea.git
synced 2026-08-03 23:04:27 +00:00
Giteabot
e0e10052e0
Backport #38753 by @Zettat123 ## Background `MinioStorage.Save` is called with `size = -1` on several paths, including Actions logs, Actions artifacts, repository archives, avatars and attachments. With an unknown size (-1) minio-go assumes a 5TiB object and allocates a single part-sized buffer of 528MiB per upload, regardless of the real payload size, which can exhaust the memory of small instances. Measured against a local S3 stub, five sequential uploads of a 4KiB payload grew RSS by 1041MiB before the fix and by 34MiB after it. ## Fix Pass an explicit 16MiB part size in that case, the same value minio-go uses as minimum part size (https://github.com/minio/minio-go/blob/v7.2.1/constants.go#L28). Uploads with a known size are left untouched, since minio-go already derives a part size proportional to the real object size. ## Note: One behaviour change: with an unknown size the object is now limited to 16MiB * 10000 parts = 156.25GiB (https://github.com/minio/minio-go/blob/v7.2.1/api-put-object-common.go#L112-L116). `putObjectMultipartStreamNoLength` completes the upload once it runs out of parts without checking that the reader was drained, so a stream past that limit is silently truncated rather than rejected. The previous limit was 5TiB. No payload Gitea uploads comes close to either. Parts are also uploaded serially, so a smaller part size means proportionally more round trips for large unknown-size uploads. Co-authored-by: Zettat123 <zettat123@gmail.com> Co-authored-by: silverwind <me@silverwind.io>