Not to bring this back from the dead but- howdy Shaun!! Long time no see . This is a shot in the dark but why not:
1) Did you guys ever figure out what was causing the CPU spike on the AGS for some SOC processes?
2) If so, do you recall what the issue or culprit was?
We have just recently started seeing much higher than "normal" CPU utilization from 2-3 SOC processes (intermittent but reproducible with light service use) that just started in the last week. It's bringing our prod server to a near stand still and 100% utilization when there are several users hitting our apps from the services. Also nothing in the logs that jump out. Any help or ideas would be greatly appreciated- hope all is well in Lynchburg!
What kind of services are you running that you see this issue with? Composite Geocoders can cause a larger load due to the nested data access.
Also various Geoprocessing tools can cause a spike after various OS patches to address security exploits from earlier this year.
Also consider taking a look at your Anti-Virus software; some configurations can see each time a service or its data is accessed that a AV scan of the data/files will be triggered which can cause the service to spin in a waiting-to-load state.
Thanks for the reply David. We are seeing these delays / CPU utilization issues from standard map services that are referenced in a series of 10.3.1 Portal web applications. What is strange is that this was never an issue before a few weeks ago (checked and no Windows updates have been applied / nor Esri), and I cannot reproduce this behavior on our dev tier which mimics our prod tier. In the dev tier (and previously in prod) I can get CPU to spike to ~30% with some panning around (especially high multi-family areas where parcel drawing is more resource intensive) but never much more than that. The same app, same zoom extend and area panning now in prod will spike to 80-90% CPU and stay there for a little while after the draw is complete.
The only things that are different between prod and dev is:
Good suggestion on the antivirus as well- I'll have my IT folks confirm that nothing new has been setup or that nothing is regularly running or scanning the directories AGS needs to access for SOC operation.
Any other ideas or thoughts are welcome. Thanks all!
I would also consider looking at your Performance Monitor; get a look a the amount of memory each SOC is using and the amount of total SOCs running. Considering the performance hit of apps/service hitting the local pagefile; you may also be seeing a memory/swap contention type issue.
I usually shoot to have 128-256mb of RAM for each expected SOC; and when I am looking at setting up services for things like GeoProc I will have these create/write/delete a intermediary fGDB and avoid using InProc layers/features.