Latest Contributions by RexRobichaux3

Thanks for replying Irene! Apologies as I should have mentioned our environment earlier. We are using a standalone (for the time being) ArcGIS Server 10.4.1 and transferring to a standalone 10.4.1 ArcGIS Server- both with Web Adapters co-located on the same boxes. I think the default ports @6080 are working as the tool is able to retrieve a valid list of services from the origin server... I'm really stumped as to why it's unable to locate the service .mxds though. I have a few suspicions that I might test out specific to our environment / past practices: First is that most of our legacy services in the past were published from local client locations vs shared network locations (we have since changed that workflow). I wouldn't think that should matter since the service .mxd is still located / copied to the ArcGIS Server under the respective C:\arcgisserver\directories\arcgissystem\arcgisinput\service directories but you never know. When the origin ArcGIS Server was configured, it looks like admin access through Web Adapter was disabled... so I'm wondering if this is blocking the script from accessing some required contents through the server/arcgis/ Web Adapter endpoints. When we publish, we typically don't publish directly to server, but rather create service definition files, then through Server Manager we create services from the .sd files as this plays a little nicer with some of our web mapping applications... although doubtful, I'm wondering if this is somehow coming into play. All of these should be easy enough to test out. Thanks again for any ideas you might have! ... View more

Wow- lots of great conversation and input here. Thank you all for contributing. If I'm following this properly, it sounds like with our current (relatively simplistic AGS deployment), it might be worth trying the Join Site route? If that doesn't work out, it sounds like Jonathan's suggestion (last 4 steps) might be worth trying- did I interpret that correctly? I've not ever setup a multi-machine site (even temporarily), so I'm assuming the secondary / newer ArcGIS Server that gets added to the site shares the same Server Enterprise License as the original machine? Just want to ensure we have our licensing ducks in a row as well ahead of time. Thanks again everyone!  ... View more

A bit of a shameless plug here... in speaking with our Oracle reps and facing a near organization-wide upgrade to Oracle 18c early next year, I have submitted an ArcGIS Idea for 10.6.x / Oracle 18c (12.2.0.2) certification found here: https://community.esri.com/ideas/15892  and also have an enhancement request created with Esri Support. Feel free to vote away!   ... View more

Thanks again Shaun and David for the replies and help! I have a few updates to pass along just in case anyone suffers this CPU behavior going forward. It looks like there are a myriad of issues causing our problems for our production server. The steps we have taken and the issues that have been identified: We migrated our VM server to a new host with better processing resources. Our production server seemed to like this as even though we still had higher-than-we-used-to-have levels of CPU utilization, it was no longer maxing out resources and bringing apps and services to a haulty- so we likely had some underlying hardware issues. We further improved performance by adding all of the arcgis server directories to the exemption list of (both) antivirus applications running on the server. These same antiv applications run on all of our servers including dev, but they seemed to be going a little wild on production- IT is looking into why. With all of this done CicsoAMP still seems to be going crazy so we are looking into why CiscoAMP is having issues in this environment. We have had to completely deactivate CiscoAMP for the time being until we figure out why. The directories we admittedly over-zealously added:  c:\arcgisserver c:\Program Files\ArcGIS\Server c:\Python27 c:\Program Files\Esri c:\ Program Files\Common Files\ArcGIS c:\app\Oracle (our oracle client on the server) c:\Webservices\Data (our file geodatabase storage directory for GIS published data) e:\arcgiscache (cached aerials directory on the server) It appears that using the search widget in any app, without specifying a map service layer, is a major contributor to the CPU usage. As any one of our apps has between 15 and 25 searchable layers, this is not really surprising. Therefore we will have to continue with more end-user education that when using the search widget, the layer of interest needs to be specified. We have always been pretty religious with this messaging but there maybe a new hire or app user who doesn't know this or has forgotten that is unknowingly really slowing things down. I also have a case open with Esri support to verify that this issue is expected behavior and not a bug.  Hope this helps guys- if we figure out anything else I'll update this.  Thanks again for the info and assistance! -Rex ... View more

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 ... View more

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! -Rex ... View more

Hello Joshua,   Sorry to bring up an old thread but I was wondering what the SQL query of the states or state lineages table you ran against the GDB was to generate the WIL_sde_states.txt parse file? Thanks! -Rex  ... View more

As Robert mentioned- do you have any common unique attributes / data between your exported table and the original / soon to be restored data? Perhaps line segment ID, Asset ID, etc.? If so it should be fairly easy to join up the data via append, data loader, etc. However, if there are no coincident attributes between the two sources (assuming one spatial and the other tabular only) you might have to achieve this manually.   If the personal backup data you mentioned was exported as a shape- you should still have spatial components to the data or possibly I'm misunderstanding the state of the data sources you have? Hope this helps! ... View more