How to determine the number of min\max instances (ArcSoc.exe) for a particular map service based on its number of requests?
I couldn’t figure out if there is a mathematical equation that relates the number of min\max instances (ArcSoc.exe) for a particular map service with the number of requests. In other words, is the number of min\max instances (ArcSoc.exe) a function of its number of requests?
Y=f(X), where:
Y: the number of min\max instances (ArcSoc.exe) for a map service
X: the number of requests
For example, if the number of requests for a particular map service is 100, what could be the best choice for the number of min\max instances (ArcSoc.exe)?
Thank you
Best
Jamal
We have found 250 instances to be the max, regardless of ram/cores. That could be 5 services each with min instances set to 50, or 25 services with min instances set to 10. Coincidentally, this applies to a multi-machine site as well. 3-machine cluster? Anything more than 25 services with min instances set to 10 and it starts wobbling.
Concur. ~200 services with the default 1 min instance is the max number of services we have seen ArcGIS Server be stable at.
You may be running into a limit with the non-interactive desktop heap:
https://support.esri.com/en/technical-article/000001218
However, I think Subramanian Swaminathan is correct, there may be stability issues as you force Server to support hundreds of services. I believe that shared instances introduced at 10.7 is a solution for that, though.
Prior to 10.6.x, I would agree with you. Starting with the changes Esri made in 10.6.x and continued with 10.7.x, we are able to push the number of services much higher.
Many thanks guys for sharing the experience. Very much appreciated
I thought that there should be direct association between the load (map services) and machine resources (cores/ram)
Thanks Ahmad. We will be considering the “ArcSoc Optimizer Add-on” and find out if it brings a good tool to design the best fit between the load and resources. However, this tool is very costly as I got.
Thanks Jonathan. We will be configuring the Registry Editor as it is recommended. We will provide our feedback. We need also to better explore the concept of the “shared instances” of the 10.7
Thanks Thomas. I’m still wondering how the total number of ArcSoc.exe assigned for min\max for all services in a machine is not related to the recourse. Does a machine of 4 cores works the same as a machine of 32 cores?
Assuming no load or requests are making it to the Server, the number of services you can publish to a 4 core and 32 core machine should be the same as long as the machines have the same amount of RAM. There's a bit of internal overhead for managing services and more cores will handle that better, but in general, it should be roughly the same.
Once the machine starts taking requests, you'll need to monitor the usage and resources and make adjustments as necessary.
Thank you Jonathan Quinn for your reply, this is what we have done before (monitoring), but now with the sharing instances option in Arcgis 10.7.1, we think it is a good approach, but why not to have the sharing option at the level of the site and not per service?y
I think you can change the behavior by
Thank you Ahmad for your reply, do you mean that changing the default instance type per site to “shared instances” will affect all the services, and all the services will share the number of instances? and in this case we don’t need to apply the pooling setting per services as shown below.
Best
Majdoleen
How the number of arcsoc.exe (instances, processes) is associated to the machine resources (cores, ram)?