Welcome Guest Search | Active Topics | Sign In | Register

CPU usage and processes left running with EO.PDF Options
Panda
Posted: Sunday, March 18, 2018 9:04:14 PM
Rank: Advanced Member
Groups: Member

Joined: 10/7/2015
Posts: 35
Hi,

We are trying to solve an issue where the creation of PDF's ultimately brings the server down due to the number of processes and CPU usage.

I firstly wanted to know if there could be any reason why so many processes are being left behind without using CPU? (see image below)
These are using a lot of memory and I'm wondering if this is a setting or something we can do about it?
Like, is there a setting that forces only loading on demand or something like that?

For the CPU hanging, I suppose we'd need a dump of some kind before you could have any idea what the problem is, though we do know that the page itself loads without any issues outside of the PDF creation.

https://www.dropbox.com/s/oh68ra95vjtesc1/cpu-pdf.png?dl=0




eo_support
Posted: Monday, March 19, 2018 10:49:33 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

It's normal that there are many child processes. They are dynamically created and released. So if there is no load, these processes will stay idle and eventually exits. If the system has been idle (no conversion tasks) for a long time (> 20 minutes) and they are still there, then that indicates a problem.

The number of child process directly corresponds to number of concurrent conversion task you have. By default, you will have 6 to 8 child processes. However if you have many conversions running at the same time, then the number of child processes can increase significantly. If you have too many child processes and the conversions are extremely slow, then that is usually an indication of an system overload. In that case you should reduce the number of concurrent conversions. You can use this property as a safe guard to prevent too many concurrent conversions:

https://www.essentialobjects.com/doc/eo.pdf.htmltopdf.maxconcurrenttaskcount.aspx

Having a large number of child process does not necessarily mean they consume a lot of memory. See the last post in this thread for more details:

https://www.essentialobjects.com/forum/postst8270p2_RunDLL32-and-Memory-Footprint-of-EOWebBrowser.aspx#43275

Please feel free to let us know if you have any more question.

Thanks
DWhite
Posted: Monday, March 26, 2018 10:19:18 PM
Rank: Newbie
Groups: Member

Joined: 3/26/2018
Posts: 2
Hi Support,

Unfortunately on our server the child processes aren't terminating after the idle timeout of 20 minutes and as a result are hanging around and filling up memory.

Please see the screenshot below:



As you can see a number of processes are over an hour old and we know from our logs that there aren't that many conversions running concurrently so most of those processes should be idle.

Can you please help resolve whatever issue is preventing the child processes from terminating?
eo_support
Posted: Tuesday, March 27, 2018 8:34:22 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Hi,

Please check which version of EO.Pdf you use. Our old version did have an issue that could leave orphaned eowp.exe. Newer version has additional code to monitor eowp.exe and terminate them if needed. So please try the latest build and see if it resolves the issue for you.

Thanks!
DWhite
Posted: Monday, April 16, 2018 8:48:12 PM
Rank: Newbie
Groups: Member

Joined: 3/26/2018
Posts: 2
Hi,

We've upgraded to v18.1.31 but are still having a problem with the child processes not terminating when idle for more than 20 minutes.

Most of the processes take up over 100MB of memory, see below screenshot (server time was 12:24AM):

https://ibb.co/iNDLj7

Can you please let us know what to try next? Thanks.
Tyler Miller
Posted: Monday, September 3, 2018 4:33:15 PM
Rank: Advanced Member
Groups: Member

Joined: 1/22/2014
Posts: 38
Any work on whether this actually was resolved by the newer releases and if so which release?
eo_support
Posted: Monday, September 3, 2018 5:44:10 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Tyler Miller wrote:
Any work on whether this actually was resolved by the newer releases and if so which release?


There have been various different issues that can cause and have been resolved (for example, you can search "hang" in our change logs and you will see a number of entries). Typically for such issue we request a test project from our user, run it here and then identify/fix the root cause for that specific scenario. Due to the extremely large size of the Chromium project, there could still be other extreme/rare scenarios that we are not aware of that can still cause such problems (even Chrome browser crashes/hang sometimes). So there is really no single point where we can claim that we have completely eliminated such issues because underlying they can be completely different issues. As such the best option is for you to try the latest build first. If you still see problems, you might be running into something that other users have not run into yet. In that case you can try to isolate it and send it to us and then we will investigate. See here for more information on how to send test project to us:

https://www.essentialobjects.com/forum/test_project.aspx

Thanks!
Tyler Miller
Posted: Tuesday, September 4, 2018 1:11:24 AM
Rank: Advanced Member
Groups: Member

Joined: 1/22/2014
Posts: 38
I'm trying the latest version as a trial to test the hanging fix is there any reason it would be much much slower than the 18.0.55 I'm currently using? It has to be 3-4 times slower on everything.
eo_support
Posted: Tuesday, September 4, 2018 5:07:52 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,067
Tyler Miller wrote:
I'm trying the latest version as a trial to test the hanging fix is there any reason it would be much much slower than the 18.0.55 I'm currently using? It has to be 3-4 times slower on everything.


We are not aware of such issues. The most common bottleneck for the HTML to PDF converter is usually the web server because the HTML to PDF waits for everything to be loaded first before performing the conversion. For example, a single slow loading picture can hold up the whole conversion. You can try to comment out your HTML block by block to see if you can find out the bottleneck. If you still believe that there are serious performance degradation between the two versions, you can send us a test file and we will be happy to investigate further.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.