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

Memory leak when reading s3 object #4342

Open
1 task
ozturkberkay opened this issue Nov 12, 2024 · 2 comments
Open
1 task

Memory leak when reading s3 object #4342

ozturkberkay opened this issue Nov 12, 2024 · 2 comments
Assignees
Labels
bug This issue is a confirmed bug. p3 This is a minor priority issue s3

Comments

@ozturkberkay
Copy link

Describe the bug

Using get_object function and reading the Body is causing a memory leak.

Regression Issue

  • Select this option if this issue appears to be a regression.

Expected Behavior

The memory should be freed after the object body is not referenced anymore.

Current Behavior

RSS does not go down unless the script runs idle for 40 minutes (see the graph below).
Deleting the python objects, calling gc.collect(), or closing the boto connection are not fixing the problem.

image

Reproduction Steps

import os

from botocore.config import Config

import boto3

BUCKET = "bucket"
KEY = "key"  # +5 MiB size

session = boto3.session.Session(
    aws_access_key_id="key",
    aws_secret_access_key="secret",
    region_name="region",
)
s3_client = session.client(
    service_name="s3",
    endpoint_url="http://localhost:9000/",
    config=Config(tcp_keepalive=False, max_pool_connections=0),
)


def run():
    for _ in range(50):
        resp = s3_client.get_object(Bucket=BUCKET, Key=KEY)
        with resp["Body"] as stream_resp:
            stream_resp.read()


if __name__ == "__main__":
    run()

image
image

Possible Solution

No response

Additional Information/Context

No response

SDK version used

1.35.58

Environment details (OS name and version, etc.)

Mac OS 15.1 (24B83), Python 3.11.9

@ozturkberkay ozturkberkay added bug This issue is a confirmed bug. needs-triage This issue or PR still needs to be triaged. labels Nov 12, 2024
@adev-code adev-code self-assigned this Nov 14, 2024
@adev-code adev-code added investigating This issue is being investigated and/or work is in progress to resolve the issue. s3 p3 This is a minor priority issue needs-review and removed needs-triage This issue or PR still needs to be triaged. labels Nov 14, 2024
@adev-code
Copy link

Hey @ozturkberkay, thanks for reaching out. I have replicated the same steps and able to get the same graph. Observing the graphs you have provided and from my side, there's no indication of memory leak. This is because the graph stays flat and constant and if there was a leak, then the graph would have continuously increased. The way Python's memory allocation works is it will defer memory allocation until absolutely needed by Python's memory manager. Once that's done for large objects, it will generally hold memory, even if the objects are freed for future use. This leaves the blocks free for Python to use and won't return them to the OS. Please let me know if you have any questions. Thank you.

@adev-code adev-code added response-requested Waiting on additional information or feedback. and removed investigating This issue is being investigated and/or work is in progress to resolve the issue. needs-review labels Nov 27, 2024
@ozturkberkay
Copy link
Author

@adev-code Thanks for taking a look. I just wanted to understand where the overhead is coming from and how can I make sure it is deallocated once not needed. Compare this to reading from a file, you will not observe such behavior.

You can close the issue.

@github-actions github-actions bot removed the response-requested Waiting on additional information or feedback. label Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a confirmed bug. p3 This is a minor priority issue s3
Projects
None yet
Development

No branches or pull requests

2 participants