At the Architecture Practice, we are getting a lot of questions about shared instance pools.
Before 10.7.0, the solution for reducing the amount of RAM was to set low-utilization so that the minimum number of instances in that service’s dedicated pool to zero. By doing so, you allow ArcGIS Server to not run any ArcSOCs for the service if it hasn’t received any requests in a while.
This “min-zero” solution eliminates the resource usage for services that are going unused. Because you can still set the maximum number of instances, you can accommodate services that receive infrequent bursts of traffic. The next time the service gets a request, an ArcSOC powers up to handle it at the cost of the startup time of the ArcSOC. Also, this service could then sit idle for a more extended period, consuming the started SOC until the service hits the set idle timeout.
At 10.7.0, Esri announced support for shared instance pools. Every ArcGIS Server Site now comes with a shared instance pool, containing four ArcSOC processes by default. This number can increase to accommodate more services. The shared instance pool utilizes all of the SOCs assigned to it, so you should only increase the pool as you need to.
Once a compatible map service has published to your ArcGIS Server Site, you can designate it to use the shared pool. Any service added to the shared instance pool will no longer have its dedicated pool; it will dip into the shared pool and use a SOC or two as needed. Once it’s done handling a request, that ArcSOC is free to be used by any other service in the shared pool.
The following restrictions limit what services can use the shared instance pool:
For further information, please see:
Introducing shared instances in ArcGIS Server 10.7
Configure service instance settings—ArcGIS Server Administration (Windows) | ArcGIS Enterprise
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.