Possible Memory Leak in the JpegViewer

[JeepLavoie]

Please, fill the following sections to help us to reproduce and fix the issue

What happened:

When running the GroupDoc.Viewer.UI.SelfHost in Docker and Kubernetes I saw that the instance was using a lot of memory and not release it.

When reading the JpegViewer.cs in the master branch, I saw that the MemoryStream declaration at the line 42 don't use the Dispose() or using pattern like Microsoft recommend.

What you expected to happen:

The MemoryStream use in all the Viewer are dispose after they are use.

How to reproduce it:

• Create a new C# Web Api.
• Follow the instruction in the project README.MD
• Use the LocalFileStorage without cache.
• Set the ViewerType to ViewerType.Jpg
• Deploy using Docker and Kubernetes
• View some heavy PDF and Word file
• Check the memory usage of the Pod, it max out quick.

Source code sample:

No code sample available.

Environment: AKS with Ubuntu Agent.

• .NET Core version : SDK 6.0.411
• GroupDocs.Viewer.UI version : 6.0.13
• GroupDocs.Viewer.UI.SelfHost.Api version : 6.0.15
• Operative system: Last version of mcr.microsoft.com/dotnet/aspnet:6.0 docker image.
• Others:
  • Kubernetes version 1.26.3

[vladimir-litvinchik]

@JeepLavoie

Thank you for opening this issue and sharing the details.

@vyacheslav-prokopenko please take a look

[vyacheslav-prokopenko]

Hello @JeepLavoie. It seems the problem is not with using or Dispose(). You can check official microsoft documentation https://learn.microsoft.com/en-us/dotnet/api/system.io.memorystream?view=net-6.0

The Note in the middle of the article This type implements the IDisposable interface, but does not actually have any resources to dispose. This means that disposing it by directly calling Dispose() or by using a language construct such as using (in C#) or Using (in Visual Basic) is not necessary.

We will check additional cases further such a InternalCaching

Default value is 5 minutes so it can be the problem converting large files.

You can disable that

builder.Services
    .AddControllers()
    .AddGroupDocsViewerSelfHostApi(config =>
    {
        config.ConfigureInternalCaching(options =>
        {
            options.DisableInternalCache();
        });
    })

Or change duration

builder.Services
    .AddControllers()
    .AddGroupDocsViewerSelfHostApi(config =>
    {
        config.ConfigureInternalCaching(options =>
        {
            options.SetCacheEntryExpirationTimeoutMinutes(1); 
        });
    })

And if you can provide some examples of docker/kubernetes settings it will be great so we can try to reproduce that on containerized environment

[JeepLavoie]

Hello @vyacheslav-prokopenko, I had already disable the InternalCache.

Like show in the screenshot you can see the 4 kubernetes instance that are running and their memory usage. The only code that is running in those Docker Container are the GroupDocs.Viewer.UI.

Can you help me to diagnose the possible high memory usage.

Those are the HelmAndDockerfile.zip that we used in our project.

Thanks

[vyacheslav-prokopenko]

@JeepLavoie thank you for new data. I'll investigate what we can do with that

[vyacheslav-prokopenko]

Hello @JeepLavoie . As I understand from screenshot that every docker instance has 1GB memory and from 500 to 800 MB memory usage. Can we get some example of incoming files sequence for GroupDocs.Viewer.UI in the containers? If it's not possible to provide examples of the files so at least just list of file type + file size? Is that some pdf (or word) files "incoming stream" or list of mixed formats?

[JeepLavoie]

Hello @vyacheslav-prokopenko,

First we saw that the memory limiting was causing some issue with GroupDocs.Viewer. With 1 gb of ram with this PDF
SGT-Information-et-sensibilisation-1.pdf was giving Out Of Memory Exception. So we remove all memory limit in K8s. For the generation Issue. When generating with this PDF large pdf.pdf with can have over 1GB of memory usage for one instance.

I hope this information and those file can help you.

Thanks 😄

[vladimir-litvinchik]

@JeepLavoie

We have found a hot spot in our code where we processing graphics in PDF files. As soon as we have any updates we'll let you know.

[JeepLavoie]

@vladimir-litvinchik

Thanks for the follow-up.

[CmortonDCM]

@vladimir-litvinchik has there been any progress on this one?

Thanks

[vladimir-litvinchik]

@CmortonDCM

The development team has located the issue. I'm waiting for the feedback about their plans. Will let you know as soon as I get any new information.

[denis-gvardionov]

Hello @JeepLavoie !

Sorry for the delay. This issue is successfully resolved in the GroupDocs.Viewer for .NET version 24.3. Please update the GroupDocs.Viewer library in the GroupDocs.Viewer.UI project and that's all.

We improved both memory consumption and processing time while converting different PDF files to JPEG and PNG formats. You previously provided 2 sample files - "SGT-Information-et-sensibilisation-1.pdf" and "large pdf.pdf", as examples of poor performance. Here is a comparison of performance and memory consumption for these two files between old and new GroupDocs.Viewer.

"SGT-Information-et-sensibilisation-1.pdf", converting all 8 pages:

GD.Viewer version	JPEG, Memory, Peak, MiB	JPEG, Memory, After cleanup, MiB	JPEG, sec	PNG, Memory, Peak, MiB	PNG, Memory, After cleanup, MiB	PNG, sec
23.3	1500	690	9	1700	672	9
24.3	249	187	5	224	186	5

"large pdf.pdf", converting all 56 pages:

GD.Viewer version	JPEG, Memory, Peak, MiB	JPEG, Memory, After cleanup, MiB	JPEG, sec	PNG, Memory, Peak, MiB	PNG, Memory, After cleanup, MiB	PNG, sec
23.3	434	217	108	256	194	108
24.3	268	211	44	336	212	45

Of course, these numbers are relative to specific machine and its specs, OS, .NET runtime, settings etc., but you can see a state of things in general.