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

ImageSharp Potential Memory Leak #7826

Closed
olegbogomaz opened this issue Dec 2, 2020 · 1 comment · Fixed by #11585
Closed

ImageSharp Potential Memory Leak #7826

olegbogomaz opened this issue Dec 2, 2020 · 1 comment · Fixed by #11585

Comments

@olegbogomaz
Copy link

We are currently running a single non production Orchard Code instance and have encountered a performance issue. Our current investigations and research are pointing to a memory leak. It appears the application does not always release memory so performance deteriorates over time and the application ends up crashing eventually. We currently run approximately 200 test tenants and use media with real time image resizing.

We’ve spent a good amount of time analyzing the memory dumps and performance metrics and we believe the issue could be in SixLabors.ImageSharp.Memory.ArrayPoolMemoryAllocator.

As the next steps we were going to try managing memory allocation for ImageSharp with the following settings:

Configuration.Default.MemoryAllocator = ArrayPoolMemoryAllocator.CreateWithModeratePooling();
Configuration.Default.MemoryAllocator.ReleaseRetainedResources();

https://docs.sixlabors.com/articles/imagesharp/memorymanagement.html

Do you have any additional insights or recommendations?

Our Current Configurations:

Azure AppService Tier:
S1 - 100 total ACU, 1.75 GB memory

Databases:
Approximately 200 Azure SQL databases under SQL elastic pool

Media:
Azure Blobs

Thanks.

@deanmarcussen
Copy link
Member

I can't offer any special insights into ImageSharp memory management - other than to say I have used some of the constrained memory configurations with Azure Functions (limited ram) previously.

What I have seen is that in a constrained memory environment it is possible to force, or receive, bad requests, when trying to real time resize many images at once - these generally result in a 500 error, but will complete on the next request.

I've never analysed that to see if it resulted in any memory leaks, but it might be interesting for you to check your logs to see if you are hitting memory limits.

You might want to open an issue with ImageSharp, I (think) the memory management part of it is managed at an ImageSharp level, rather than an ImageSharp.Web level, if that makes sense.

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

Successfully merging a pull request may close this issue.

2 participants