10.4.1 vs 10.5

[DaveTenney]

All,

  looking for some real world input from those who have used 10.4.1 for server and have recently upgraded to 10.5

we have been trying to vet 10.4.1 in our staging environment to be used in our production environment and at this point in time we cannot vet 10.4.1. i dont want to get into details here on that, we are providing a lengthy response to this directly to ESRI.

what i would like to know is how people feel about 10.5 so far? were you experiencing issues with 10.4.1 that seem to be resolved with 10.5? i would assume we are fairly close to a 10.5.1 release (around the time of the UC). again, just looking for some real world users and your input.

thanks,

dave

[DaveTenney]

i would have to get with the tech guys that run the load balancer and ask them.

   i find it very interesting that this isnt an issue with 10.2.2, it would be interesting to know what has changed from 10.2.2 to 10.4/10.5 that were now seeing this behavior.

[MichaelVolz]

This issue also exists at 10.3.1 in a load balanced environment.  It's been a problem for some time.

[DaveTenney]

im assuming ESRI thought this issue was fixed with 10.5? as they are really pushing it as an enterprise solution with the use of load balancers?

[DaveTenney]

Just an update...

     we adjusted our script to not kill any rogue arcsocs left behind, we told it to only continually look back and check to see if there are instances still running.

1) stop service

2) check for rogues...yes...wait

3) check for rogues...yes...wait

4) check for rogues...no...move on to next service to stop

repeat

we were able to stop the first service with no rogue arcsocs

   the second service had rogue arcsocs for 4 days, we finally had to stop the test!

how is it possible to send the basic function to stop services, and still have instances running on the machine for days!?!

   the real kicker is that according to the admin interface the service was stopped configured/real-time, and, there were no arcsocs of the service in question listed within the task manager of the machine.

strange things are happening!

dave

[MichaelVolz]

Dave:

Are you performing this testing in a development or production environment?

If this testing is in a development environment that is load-balanced, are you getting a heavy load on the development AGS servers?

I ask these questions because I was performing some testing in my development 10.3.1 load balanced environment where address locators could not be rebuilt due to locks from geocode services that should have been stopped.  I rebooted the servers (Has not been done in at least 6 months) and ever since the geocode services stop properly and the address locators get rebuilt as expected.  As such I'm thinking that the zombie processes are caused by the accumulated load on the servers which is much harder to duplicate in the development load-balanced environment as the load is so much lower than in production.

[Anonymous User]

Hi Dave,

We have also migrated our ArcGIS server from 10.4.1 to 10.5 without any issue.

After upgrade & install new version of AGS 10.5 Map services response time is much better than previous 10.4.1.

Also observed the map service recycle issue like map services goes in stopping phase in previous version got fixed almost(from 3 months no issue).

AGS & map service up time improved from 10.3.1 (less then 5 min its takes to up and running with 80 map services).

Is there any thing we need to check from performance point of view.

[DaveTenney]

Wanted to provide an update since it has been awhile...

    as far as geocode services are concerned we found that we had to stop them in a particular order. we found that if there were any composite locators using other locator services, the composite locator needed stopped first. this wasnt any issue in 10.2.2, not sure if that release was just "dumb" and didnt care, but we have noticed in 10.5 and 10.4 that we had to change the order in which our python script went in when stopping services.

   after we resolved that problem we noticed another....go figure.

when stopping/starting services we noticed that at random the service becomes stuck in state where the "real-time" and "configured" states dont match (ie: real-time = started, configured = stopped) what happens then is our script stalls b/c the server never responds with the successful start message to allow our script to move onto the next service to start.

the only way we have found to fix this issue is to restart the esri server, and this takes anywhere from 1-5 restarts, not exactly a pretty or acceptable solution.

dave

[DaveTenney]

I believe this will be the final update.

   we have been informed by ESRI that the way were doing things successfully in 10.2.2 is no longer supported in newer version releases.

So in short, we will have to redo our python scripts to update map services and locator services.

thanks

dave

[MichaelVolz]

Did they provide you with an updated procedure for updating your locator services that will work consistently in a load balanced environment?

[MichaelVolz]

Were you by any chance using the python admin scripts that ESRI provides with the AGS install?

The script is found at the following location if you accept default install:

C:\Program Files\ArcGIS\Server\tools\admin\manageservice.py

I use it in a bat file to stop a service as follows: 

%PythonExePath% %ManageServicePyPath% -u "username" -p password -s http://"servername":6080 -n Service/Comp_Add_RD.GeocodeServer -o stop