OptimizeResources / Compression Memory Leak

Hi,

I am using Aspose.PDF (21.9.0) to bundle several thousand single page PDF’s together (14,762 in this case)

During the process, it is necessary for me to compress this document.

This is the code I am using

var oo = new Aspose.Pdf.Optimization.OptimizationOptions();
oo.ImageCompressionOptions.ImageQuality = 20;
oo.ImageCompressionOptions.MaxResolution = 144;
oo.ImageCompressionOptions.ResizeImages = true;
oo.ImageCompressionOptions.CompressImages = true;
oo.ImageCompressionOptions.Version = Aspose.Pdf.Optimization.ImageCompressionVersion.Fast;

Parallel.ForEach(pages, page =>
{	
	using (Document page = new Document(page.FilePath))
	{
		page.OptimizeSize = true;
		page.OptimizeResources(oo);
		page.Save(page.CompressedPath);
	}
});

The machine running this has 4 cores and 14GB of RAM

As you can see from the image below, the memory used for the compression of each page is never released.

image.png (32.4 KB)

Leaving this process running will eventually hit maximum memory usage and fall over.

I have tried joining all the files together and running a single compression operation, however, this also has the same issue.

What can you advise to avoid this problem?

@TomKirkland

We need to test this scenario in our environment in order to determine the root cause of the issue. Could you please share the final PDF document that you obtained after joining different files? We will try to compress it using shared code snippet in our environment and share our feedback with you. In case the PDF file size is larger, you can upload it to Google Drive or Dropbox and share the link with us.

Hi,

I cannot attach the final, uncompressed, PDF as it is extremely large.

Instead, I’ve done a separate test where I use the attached file in a loop to simulate a few thousand pages.

This was the RAM usage during that test
image.png (37.6 KB)

This was the file I looped with
Rose First Published Article.pdf (1.0 MB)

@TomKirkland

We are sorry for the trouble. Would you please share the code snippet as well that you used to perform a separate test? We need to exact the same code snippet to test the scenario at our end so that we can try to observe similar results that you are noticing and address the issue accordingly.

Hi, the code is the same as my example in the first post.

The list of pages is just filepath strings.

In my standalone test each document is simply 9 rather than 1 page

@TomKirkland

We were able to notice the issue in our environment and have logged it as PDFNET-50610 in our issue tracking system. We will further look into its details and keep you posted with the status of its correction. Please be patient and spare us some time.

We are sorry for the inconvenience.

Hi,

Is there a workaround you can suggest for this issue while it is being fixed?

Many Thanks,
Tom

@TomKirkland

We are afraid that we cannot share any workaround at the moment as the logged ticket is not yet investigated. As soon as it is fully analyzed, we will be able to share some updates with you. Please give us some time.

We apologize for the inconvenience.

@TomKirkland

Can you please try using the latest version i.e. Aspose.PDF for .NET 22.3 and let us know in case you still notice this issue? We have tested using it and could not reproduce it.

Hi,

Unfortunately, the problem still persists.

For a bit more context, I am running this code as part of a net 6.0 docker container on Linux in Azure. The code includes Aspose.PDF 22.3.0 and Aspose.Words 22.3.0 (although this is used for something else much later on in the process)

When I run the container locally using Visual Studio (on Windows), everything is fine - as each page is compressed the memory cycles in and out.

When I run locally using Docker Desktop (Linux Containers) I encounter the same problem as described above where by after each page is compressed the memory is not released which eventually crashes the machine.

@TomKirkland

Thanks for providing more details. We have re-opened the ticket to investigate the scenario in particular environment and will let you know as soon as we have some results.

@TomKirkland

Your code was reproduced using docker container (Linux) for sixteen copies of the attached file. No hangup occurred in our environment.

The attached archive file contains the application used for testing (the files to be optimized are located in the “docs” folder).

If this is still not the case, please share the used project with the used code snippet and docker file.