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:
- Our prod server (VM ware, 16GB RAM, 4 core hyper VM with Windows 2012R2, Intel Xeon E5-2695 V4) is a new "clone" of our old VM server as of a month ago. However IT has assured us that from a hardware perspective, our specs are identical. The dev machine has identical specs as well.
- Our spatial data that is used for web app consumption come from two file geodatabases that also live on the respective servers. We recently switched from using one-way child to parent replication to update these file geodatabases (from our production enterprise geodatabase) bi-weekly, to a python script that truncates and appends all of the data from our Prod Oracle EGDB.
- Im currently in the process of making new copies of these FGDBs and deleting the GP history / metadata that has accumulated due to this recurring truncate and append. Hoping to test performance from the new FGDBs tonight.
- We also compacted these two FGDBs a few weeks ago in hopes to increase performance. We did not compact the FGDBs in the dev tier. Hoping my testing of the above GP history also should test out if the compacting of these two data sources (and possibly subsequent truncate and appends) have caused any issues.
- I have added an additional max instance to each service on the production server. Doesn't seem to have had much affect from today's initial testing.
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!
-Rex