Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit memory usage on PutObject [faq] #1496

Closed
pizixi opened this issue May 28, 2021 · 4 comments
Closed

Limit memory usage on PutObject [faq] #1496

pizixi opened this issue May 28, 2021 · 4 comments

Comments

@pizixi
Copy link

pizixi commented May 28, 2021

What should I do if I use a lot of memory when uploading large files?

@klauspost
Copy link
Contributor

@pizixi Limit PartSize or disable multipart altogether.

@klauspost klauspost changed the title for help Limit memory usage on PutObject [faq] May 28, 2021
@harshavardhana
Copy link
Member

@pizixi Limit PartSize or disable multipart altogether.

Or provide the correct content length for SDK to automatically calculate the optimal part size.

@pizixi
Copy link
Author

pizixi commented May 29, 2021

hi:
I used your code to test @klauspost (https://play.golang.org/p/jGxIrOFE97U) and kept uploading a file of more than 300 megabytes, The memory usage increased to about 1.3G and there was no increase, there should be no memory leak, but 1.3G memory is too big for me, I tried to test with python client api, The memory usage has been stable at 33m, which is the ideal way. Is there any good way to solve this problem of minio-go? Thank you

image

@harshavardhana
Copy link
Member

	go func() {
		defer wg.Done()
		uinfo, uerr = mClient.PutObject(context.TODO(),
			"test",
			fmt.Sprintf("%s-%c", fileName, time.Now().Unix()),
			pReader,
			-1,
			minio.PutObjectOptions{ContentType: "application/octet-stream"})
		log.Printf("err %v %v", uinfo, uerr)
	}()

I used your code to test @klauspost (https://play.golang.org/p/jGxIrOFE97U) and kept uploading

If you are passing -1 as length SDK has to allocate 512MiB buffer to cater for the largest file possible to upload i.e 5TiB. So don't pass -1 as content-length - instead, specify the correct length. Such as 300MiB length in bytes.

AndreasSko added a commit to AndreasSko/reva that referenced this issue Jul 30, 2021
According to the documentation for `PutObject`,
setting objectSize to -1 causes a multipart Put
operation, which can result in high memory usage.
Something similar has already been reported in
minio/minio-go#1496

This PR changes the behavior so it tries to determine
the file size before uploading it. Should the given
io.Reader not be a file, it falls back to using `-1`.

In my testing this change has reduced the memory
usage when uploading files to OICS quite a bit:
From over 1GB for a
single user, down to <300MB.
AndreasSko added a commit to AndreasSko/reva that referenced this issue Jul 30, 2021
According to the documentation for `PutObject`,
setting objectSize to -1 causes a multipart Put
operation until the input stream reaches EOF,
which can result in high memory usage.
Something similar has already been reported in
minio/minio-go#1496

This PR changes the behavior so it tries to determine
the file size before uploading it. Should the given
io.Reader not be a file, it falls back to using `-1`.

In my testing this change has reduced the memory
usage when uploading files to OICS quite a bit:
From over 1GB for a
single user, down to <300MB.
AndreasSko added a commit to AndreasSko/reva that referenced this issue Jul 30, 2021
According to the documentation for `PutObject`,
setting objectSize to -1 causes a multipart Put
operation until the input stream reaches EOF,
which can result in high memory usage.
Something similar has already been reported in
minio/minio-go#1496

This PR changes the behavior so it tries to determine
the file size before uploading it. Should the given
io.Reader not be a file, it falls back to using `-1`.

In my testing this change has reduced the memory
usage when uploading files to OICS quite a bit:
From over 1GB for a
single user, down to <300MB.
AndreasSko added a commit to AndreasSko/reva that referenced this issue Jul 30, 2021
According to the documentation for `PutObject`,
setting objectSize to -1 causes a multipart Put
operation until the input stream reaches EOF,
which can result in high memory usage.
Something similar has already been reported in
minio/minio-go#1496

This PR changes the behavior so it tries to determine
the file size before uploading it. Should the given
io.Reader not be a file, it falls back to using `-1`.

In my testing this change has reduced the memory
usage when uploading files to OICS quite a bit:
From over 1GB for a
single user, down to <300MB.
AndreasSko added a commit to AndreasSko/reva that referenced this issue Jul 30, 2021
According to the documentation for `PutObject`,
setting objectSize to -1 causes a multipart Put
operation until the input stream reaches EOF,
which can result in high memory usage.
Something similar has already been reported in
minio/minio-go#1496

This PR changes the behavior so it tries to determine
the file size before uploading it. Should the given
io.Reader not be a file, it falls back to using `-1`.

In my testing this change has reduced the memory
usage when uploading files to OICS quite a bit:
From over 1GB for a
single user, down to <300MB.
AndreasSko added a commit to AndreasSko/reva that referenced this issue Jul 30, 2021
According to the documentation for `PutObject`,
setting objectSize to -1 causes a multipart Put
operation until the input stream reaches EOF,
which can result in high memory usage.
Something similar has already been reported in
minio/minio-go#1496

This PR changes the behavior so it tries to determine
the file size before uploading it. Should the given
io.Reader not be a file, it falls back to using `-1`.

In my testing this change has reduced the memory
usage when uploading files to OICS quite a bit:
From over 1GB for a
single user, down to <300MB.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants