|
|
Rank: Newbie
Groups: Member
Joined: 5/16/2025
Posts: 4
|
Hi
We are experiencing a strange behavior when using EO.Pdf to ConvertHtml in batches (Constant CPU usage, Memory allocation until killed?)
EO.Pdf: 23.4.5
OS: Windows Server 2022 Datacenter (20348.3692)
Hardware: Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz 2.79 GHz (Azure VM)
Our web application:
ASP.net MVC 5 with Hangfire as background processing and EO.Pdf to generate Pdfs out of our Html pages (1 single application)
Our observation:
A single Hangfire job repeatetly calls different pages on our webapplication which returns a EO.Pdf converted pdf file which is then saved into a temporary folder. At the beginning, the system behaves pretty calm.
We can see the Pdf files being saved into the temporary folder one by one (around 500-800kb in size). After some time, we can observe in the task manager that one of the spawned eowp.exe processes consumes around 20-30% CPU constantly.
It does this even when not actively converting a Pdf file (this hangfire job does some copying from other files inbetween the conversion which also takes a considerable amount of time, barely CPU just slow I/O).
Since it's "only" 20-30% and the RAM usage stays between 200-500mb (rises from 200 to 500mb then looks like GC'ed back to 200ish) it would be somewhat acceptable. It looks quite stable after all.
Things get really interesting when all of a sudden another (maybe freshly spawned?) eowp.exe joins the race with another 20-30% CPU usage. The old one from before stays "active" though.
Not only that, but it is also constantly growing in RAM usage until it's killed by the OS (our setup: 99% RAM usage when the process accumulated 4.9GB). We don't receive any exceptions in our C# code during all of this.
The system behaves increasingly sluggish as soon as the one eowp.exe starts eating all the memory (which is explainable as not only the % CPU is doubled but it's also just eating more and more RAM the system will try to free at some point)
Update 1: Both eowp.exe are --type=renderer. The RAM eater does not have the --first-renderer-process argument so I think I mixed which process goes "crazy". It seems to me that the old one is behaving correctly and another eowp.exe goes RAM eating all of a sudden.
TLDR; Pdf conversions first result in 1st eowp.exe to use constant 20-30 CPU%. After some time a 2nd CPU intensive eowp.exe starts to be visible which starts to eat all RAM until it's killed by the OS.
Code to generate PDF:
HtmlToPdf.Options.MaxLoadWaitTime = 10000;
HtmlToPdf.Options.BaseUrl = "http://domain.address/";
HtmlToPdf.Options.Cookies = new CookieCollection(); // clear, important to not block the self call
_ = HtmlToPdf.ConvertHtml(HtmlResponse, original.OutputStream);
HtmlToPdf.ClearResult(); // only added to try to prevent the RAM eater
Code to receive PDF:
Shared HttpClient GetAsync stream to file
Interesting:
Once I added the HtmlToPdf.ClearResult(); I felt that doubling eowp.exe and RAM eating starts quite a bit later.
Questions:
- Is it possible / expected behavior that non-parallel Pdf conversions could lead to running 2 higher CPU (20-30%) eowp.exe processes?
- Do you have any tips to debug this issue deeper?
- Is there a possibility to get more info about the current running EO.Engine(s) through code or 3rd party programs?
Daniel
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,365
|
Hi,
The high CPU usage from the rendering process most likely is from the part that actually renders the PDF pages. Over the years we have fixed a number of different scenarios that can cause this part to be extremely slow or even hang. For example, one issue was we constantly generate additional empty pages in the hope to fit a bigger element into the next page but it never fits. There are also infinite loading pages where a page would continuously load new contents (such as facebook feeds) and never ends. Most of such cases are associated to a specific page/Url since something in the page triggerred the problem. In that case we would need to be able to load the page/HTML here in our test environment in order to reproduce the problem and then debug into it in order to get to the bottom of it.
I would recommend you to update to the latest build first. In additional to many issues that we have already resolved, your version does not support ASP.NET built-in async features well so that may have triggered the problem as well. Once you are on the latest build, I would recommend you to add logs to track the time it took to complete each conversion. When you see the CPU spikes and never comes down, it's most likely that a specific conversion started and never finishes. In that case you might be able to find out exactly which conversion started and never finishes based on the log entries you added. Once we find that out, we can then start to narrow down the problem based on the contents of that specific page.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 5/16/2025
Posts: 4
|
Hi,
thanks for your answer, makes sense. I'll make sure to upgrade to the latest version as soon as possible and check whether it will still happen.
Since we are generating one PDF after another (synchronous) and we don't get any exception, I'm not sure that it is a conversion that never "finishes". We do get results back and the process is never stuck. It looks more like that the process is not able to shutdown properly after giving back the result (if that's even possible?).
I'll make sure to update this thread once I get more results!
Thanks again!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,365
|
Hi, We wouldn't know for sure without being able to reproduce/debug it first. One thing you can do after you upgrade to the latest build is to capture a debug dump (assuming the problem still occurs with the latest build): https://www.essentialobjects.com/doc/common/debugtools.html#debug_infoThis may give us additional information on exactly what the render process is doing at that moment. Once you capture the dump, you can send it to us through our contact page: https://www.essentialobjects.com/contactMake sure you also let us know the ID of the process in question so that we can try to match it up with the information inside the dump file. Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 5/16/2025
Posts: 4
|
Hi,
After some debugging with the debugger view (EO.WebBrowser.WebView.ShowDebugUI(); - highly recommend!) which let me fully inspect the chromium instance it turned out that one of our html pages caused and infinite loop (setTimeout but still).
We could fix this on our side and we see no longer the behavior of the eowp.exe process using constant CPU and eating RAM but it all goes back to idle now!
Personally, from an EO.Pdf perspective, I would think about closing/destroying the instance/tab once the convert has happened but I think you have good reasons to not just do this.
Thanks for your support!
Daniel
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,365
|
Ah. Thank you very much for letting us know! EO.Pdf maintains a pool of WebView objects so that it doesn't have to create/destroy them every time. This generally improves performance but obviously in your case the page will just sit there eats memory/CPUs --- until it runs out of resources to crash itself or EO.Pdf either recycles the WebView (it does that perodically) or picks the same WebView to load another "normal" HTML page. We will think about what we can do for this case.
|
|