@ansamohdsh,
As far as I can see, our developers will continue working on the issue this week. Unfortunately, I don’t have any additional information yet.
@ansamohdsh,
Our developers are currently investigating which operations with each iteration result in increased memory consumption, based on the example you provided. In your code, a presentation is loaded, followed by various manipulations, and then saved in the PPTX format within a MemoryStream object. In a separate test case, distinct from your solution, we observed no increase in memory consumption after loading the presentation and subsequently saving it to PPTX in a MemoryStream object (we conducted 1000 iterations of loading and saving your presentation from the provided example).
@andrey.potapov Thank you for the update.
Yes the issue of memory increase with each iteration is due to the operations done on the ppt. That is our use case.
Please share the details from your developers on this specific scenario.
@andrey.potapov
Friendly reminder to share the updates. It has been 13days since i shared the POC code where issue was replicating
@ansamohdsh,
We have investigated the example you provided and conducted a series of tests on it.
In the example, the average memory consumption ranged from 7 GB to 11 GB on each iteration, and there was no observed increase in memory consumption during the test runs. We conducted different numbers of iterations: 20, 50, and 100. This scenario was run cyclically within a single process for several hours and more, and memory usage did not increase with each iteration. On the initial run of the scenario, there was a memory spike from 300 MB to 7 GB, followed by an increase to 11 GB on the next iteration. However, in subsequent iterations, memory consumption did not increase and remained in the range of 7 GB to 11 GB (regardless of the number of iterations).
After analyzing the example, it was noticed that the memory-consuming operations were as follows:
- (Approximately 3 GB) - creating a presentation from the template. The presentation contains 703 slides with a total of 58,810 shapes.
- (Approximately 4.2 GB) - saving the presentation to a MemoryStream.
We also conducted additional testing based on your scenario with forced garbage collection on each iteration by calling the GC.Collect() method. The test results showed that there was no memory leak, and the average memory consumption on each iteration did not exceed 7.5 GB (70 iterations were performed).
As a result of testing, it was not noticed any memory leaks in your example, although there is a significant memory load due to the large number of elements in the resulting presentation.
Could you please clarify the following:
Are you primarily concerned about the issue of high memory consumption during presentation processing?
Are you experiencing a memory leak issue where memory consumption continuously grows until all available space is exhausted?
Thank you for the update @andrey.potapov
Please check my responses below:
- Are you primarily concerned about the issue of high memory consumption during presentation processing? Yes that is one of our concern, major concern is that memory consumption is remaining constant at 7-11Gb and not coming down even after processing of ppt is done.
*Are you experiencing a memory leak issue where memory consumption continuously grows until all available space is exhausted? Our container size is at 8Gb, so if the memory increases to 7Gb and beyond, the container crashes. Not sure why the memory does not come down in linux environment. This same code works very well in windows, where we have never experienced these memory issues.
Our Primary issue is - even if ppt is taking lets say 3-5Gbs, after the processing is done, objects should release the memory and the overall memory should come back to near normal as before the ppt operation
@andrey.potapov this issue has been pending for months and we have our builds with limitations in production.
Please help us solve it and help us understand why the memory is not released even when the ppt is prepared, processed and converted to memory stream. Ideally the memory should be released and comes down to near normal as it was before the ppt operation started.
Note: this behavior is not observed in windows environment.
@ansamohdsh,
Our developers are dedicatedly addressing this issue, and I want to assure you that we are doing everything within our power to expedite its resolution. Please know that we truly value your business and understand any frustration this situation may be causing.
@ansamohdsh,
I’ve requested information from our developers for you. We will let you know as soon as possible.
@ansamohdsh,
We continue to investigate the cause of the problem. It has been found that in ASP.NET Core WEB API applications the garbage collector (GC) works in server mode by default. In this mode memory usage increases and it can be reserved by the process and not released to improve performance, which is what’s occurring in this instance. After switching GC to workstation mode, there was an improvement in the situation with memory consumption. To switch to workstation mode, please add the following: “false” to the .csproj project file in the section. This is one method of switching GC to workstation mode.
It has been discovered that a significant amount of memory, approximately 4.5 GB, remains occupied by objects in heap generation 2 (long-living objects) after completing all operations with the presentation (creating and saving). Objects in this heap are cleaned far less frequently. Furthermore, even after completing all operations and freeing up memory, there is no guarantee that the GC will release this memory promptly. This memory may be freed by the GC at the start of a new iteration or when memory is insufficient. Additionally, this memory can be released by calling GC.Collect (this call has been added to the method: ExportToPowerPointController.Export in your code). After switching the GC to workstation mode and invoking GC.Collect after all operations with the presentation, it was reduced memory consumption. However, we are currently investigating another issue involving the incremental increase in unmanaged memory consumption after saving the presentation to MemoryStream. This memory is not being released, leading to an increase in consumption by 280 MB with each iteration.
Currently, when creating a large presentation using your code — without saving the presentation — no increase in memory consumption is observed. It remains stable at 300 MB per iteration (with the GC in workstation mode, and memory is forcefully cleaned by calling GC.Collect after all operations).
@andrey.potapov
Thank you for sharing the information.
I have few thoughts to share:
-
As per your comment, server gc mode is by default. But according to microsoft’s documentation Garbage collector config settings - .NET | Microsoft Learn
workstation mode is default. Also for enterprise applications like ours we do not see it ideal to switch to workstation mode as this would impact the throughput. -
If saving the presentation file to memory stream increases the memory footprint by few Gbs, is there a way we can save the ppt to a AWS S3 bucket using aspose ppt save method?
-
calling GC.Collect is also not a ideal way, as its a framework level garbage collection which ideally framework should handle.
-
With each iteration, without saving the presentation, why does the memory increase?
Do you have any further updates for us?
@ansamohdsh,
We have resolved the issue of gradual memory increase during each iteration of saving the presentation to MemoryStream. We also tested the solution with your sample code, and no memory increase was observed. Your scenario was run 150 times during the testing. The fix will be available in version 23.10. This release will be published in the second half of October.
thank you @andrey.potapov for the update.
We will incorporate the fix once it it available from your side and try to stimulate our scenario and understand the memory issues further.
Do keep us posted on release date.