IIS Worker Process causing high CPU and Memory

[KimberlyLight]

Current system 6.5P3

3 Web, 3APP, 2 SQL

We currently have a ticket opened with RSA, I thought I would ask the community as well. We have upgraded 3 web servers and made changes to the DB server in accordance to RSA guidelines (actually a lot more spec) . We are still experiencing high CPU and RAM on the 3 web servers for Archer.

After a lot of troubleshooting we have narrowed it down to the IIS worker process having the issues. It has been recycled and the servers were rebooted, this makes a difference for a short period of time.

This is causing slow response times, pages to not load and a general unusable system.  Very unhappy business.

We have seen the Foundation\Print.aspx is the one causing the main issues, and eats up all the IIS processing server.

[Ilya_Khen]

Interesting. Do you have any jobs running actively in JobEngine while this is happening?

[Ilya_Khen]

I would try to narrow down if this is caused by user action, IIS or Windows OS itself. E.g. I would close access to all users, restart servers and check if CPU is actively going up. Then you can do restart, shutdown Archer and check that native OS/IIS behaving fine. Once culprit is found might be easier to narrow down the case. Overall pretty hard case to resolve and comment too

[KimberlyLight]

Not many jobs at all.  Nothing that would kill the CPU and RAM on all 3 web servers.  We have narrowed it down to the PRINT function.. When that is in the IIS workerprocess, it takes up all the CPU and RAM until the process is finished.

[KimberlyLight]

this is production, we cant just turn it off.  It only started a month ago, we have not made any changes to anything, its all very strange indeed.  When we do see the CPU spikes and change the worker process in IIS its always the foundation\Print some running for 22mins.

[Ilya_Khen]

And if you replicate to QA the environment, do you see the same?

[KimberlyLight]

our replicated UAT, I logged onto one web server, and replicated 4 reports to print.  It does exactly the same thing.

[Ilya_Khen]

Do you have some script or 3rd party tool doing the PRINT to Archer?

The best debug option would be to provide your DB to RSA support for replicate and investigate.

[KimberlyLight]

I just replicated, running a report and rather than exporting it, I pressed Print.  I did this 4 or 5 times on various report sizes.  and this filled up the worker process, and even when I closed the pages on my laptop, they were still there in IIS.  I think we need to disable printing from the server, and get them to export and then print. 

Seemed to mange a small report, and can export with no impact on the server.

Is there a way to not allow huge reports to be printed?  Reduce the size, it handled a 1000 rows.

Do we just disable printing altogether. 

[Ilya_Khen]

Mm, if printing 100 records causing the issue, it is a defect definitely, which must be remediated. Otherwise, you need to disable printing overall.