IIS EssentialsAppPool
I recently installed GE on our server and for some reason the IIS EssentialsAppPool Application Pool stops every once in while. I'm still trying to debug it to figure out why. Has anybody run into this issue?
However, in the process, I noticed that the Idle Time-out is defined as 1440 minutes (i.e. 24 hours). Isn't that rather excessive, or is there a reason for it? The IIS default is 20 minutes.
Mike
-
I don't think you would want your idle timeout set at 20 minutes because that would cause the app pool to refresh and there is really no reason to do this every 20 minutes. Do you have other settings that are in place that may cause the app pool to recycle such as memory limits etc.. Not sure if you are using the adf but when were using it would cause this because we had our timeout for the adf sites too high and the app pool would grow too large. I have not had this issue with using the rest based viewers though.
0 -
Under the Recycling conditions, the "regular time intervals (in minutes)" checkbox is checked with a value of 1740 (i.e. 29 hours). I'm not sure if that was done by the GE installer or a default setting. Everything else is unchecked.
Mike
0 -
Hi Mike,
Are you applying security to the site? I ran into a situation where one of the sites I had set up would stop the application pool every time the site was accessed. The site in question was set up to test various security configurations. The fix in that case was to change the application pool identity from the "Essentials" account to the "Network Service" account.
Steve
0 -
Hi Steve,
I am applying security on all my sites and running into a similar problem as Nick, where something is causing the Geocortex Core service to stop. It's not happening everytime I hit the site like in your case. We are using a local account for the Indentity. The event logs indicate that the IIS worker process (w3wp.exe) seems to be crashing.0 -
We are having an issue that resembles some of these. The Geocortex Core and Agent services often do not restart after our weekly server reboot (controlled by our IT dept). Once we restart the services and/or recycle the IIS EssentialsAppPool everything returns to normal until the next scheduled reboot ..any ideas?
Nicole0 -
Paul Ferro,
Did you ever find the solution to your problem? I'm currently having the same issue.0 -
@Austin - Do you use a lot of Workflows in your sites? We have noticed that there is a very elusive memory leak on servers that utilize a lot of workflows. The AppPool default recycling period is 24 hrs (?), but if you increase the frequency to every 4-8 hrs, this seems to resolve the issue. Approximately how many sites are you running, workflows, users? 0 -
Tom -
We have dozens of sites, with dozens of workflows (some very heavily used) in each of those sites. We'v noticed that sometimes the workflows just stop working. The sites themselves still seem to work (users can view, pan, zoom, etc.), it's just the workflows that stop. Restarting IIS fixes the problem. I suspected it might have something to do with workflows since the problem started after deploying several new ones (and new sites), but I haven't had time to dig in and find out exactly what is causing the issue. Do you think this might be related to the memory leak you mentioned above? Now that I have something specific to target, I'll check next time we have issues. Are there any reasons why we should not just go ahead and lower the frequency?
Thank you,
Stephanie0 -
Hi Stephanie,
The problem stems from a limitation in WPF (Windows Presentation Framework) that our workflow technology uses. The issue can manifest itself in a number of different ways, but the most obvious one that your users will see is that your workflows on your site no longer function. This can also affect some server side operations like printing and exporting.
Increasing ther frequency of the App Pool recycling will help with the issue. Using GW5 workflows instead of the traditional workflows should eliminate the issue as the new workflows do not utilize WPF technology.
Please feel free to open a support ticket if you need assistance with making these changes. You can reference GE-7972 to ensure the time is not billable.
Regards,
Wayne Richard
Latitude Geographics Group Ltd.
Head Office: 300 – 1117 Wharf Street Victoria, BC Canada V8W 1T7
Tel: (250) 381-8130 | Fax: (250) 381-8132 | wrichard@latitudegeo.com
Developers of Geocortex web-based mapping software | www.geocortex.com
An Esri Platinum Business Partner0 -
@Stephanie - I would highly recommend it. We have a county client that was having similar issues and we tried recycling every 8 hrs but eventually set it to every 4 hours and their server has been stable since. A good way to check is when you run into the issue, rather than reboot the server, just manually recycle the GeocortexAppPool. If this resolves the issue, then reducing the recycle period is good. Here is an article explaining the process - Recycling Settings for an Application Pool <recycling> (https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/applicationpools/add/recycling/)
Wayne is correct that the drawback to doing this is that the recycle call can cause problems with longer running processes such as printing/exporting and complex workflows. If a recycle happens while someone is executing one of these extended functions, it will cause the process to crash (because it was stopped). However, this generally should not generally happen if if you have set "disallowOverlappingRotation = False".
We recommend that clients try to set the recycle at 12 hrs, then reduce in 2 hr increments (10, 8, 6, 4) until the server is stable. This will take several days/weeks to work through to find the sweet spot that works for your environment.0 -
Whoops. Ignore the comment about disallowOverlappingRotation. I meant to remove that. It is wrong. 0 -
@Tom - Have you ever tried setting the recycling based on memory thresholds? I have not, just wondering how effective that may be if this is a memory-leak issue. 0 -
Hello All,
From my understanding, this is not a typical memory leak situation, Windows ends up running out of "handles" and when this happens it becomes unstable and unpredictable. Regular recycling of the App Pool avoids this. As Tom points out, the optimal interval is the tricky part.
Regards,
Wayne0 -
Thank you Tom & Wayne!
I'll check to see if this might be the issue next time the workflows stop functioning. This sounds like it is most likely what we are experiencing - - - our trouble seems to occur during times that I know the workflows are being extensively used. Our interval is currently set at the default 1740 (29 hours), so I'll start at 12 hours as suggested and work my way down as needed.
Thanks again everyone!
~Stephanie0 -
@Dan - As Wayne mentioned (which I had forgotten), it is a matter of Windows App Pool not releasing the handlers that are requested by WPF. As I understand (Wayne please correct me if I am wrong), when you use lots of Workflows, each one requests a handler. There is a limited amount of handlers in the AppPool. Windows is not always the greatest about releasing them nor it's memory management in general. It's not really an issue of out of memory (e.g. RAM) in that sense, so I don't know that basing it on memory usage would be best. It could also be an issue that your AppPool recycles during a heavy load and causes failures in exporting/printing/etc. Rather we have found that using strategic times works better (e.g. 8am before the work day starts, 12pm during lunch, 4pm in the afternoon, and then again in the evening). But the fewer times the better.
I know this has been an issue that has been a problem for LatGeo for a long time but it is a limitation of WPF, ASP, and IIS. As Wayne mentioned, migrating as much as possible to Workflow 5 will help.0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
15 kommentarer