How many Services, is there a limit?

9819
11
Jump to solution
09-07-2016 05:24 PM
TimHayes1
Occasional Contributor III

I am using ArcGIS for Server 10.2.2 with SQL Server 2008 R2.

I am running 80 Map and Geoprocessing Services. 

So far, there have been no performance issues. The WebMaps I have created using the Local Layer Widget (all hosted internally, not using AGOL) work fantastic.

But, i keep getting requests for "more please".

How many Services can be run from ArcGIS for Server? is there a limit?

thanks. 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
FC_Basson
MVP Regular Contributor

Like Derek Law‌ says, your server specs will determine the number of services you can run, especially the amount of memory available.

Looking at the processes in the Task Manager, you should take note of the Memory (Private Working Set) for each ArcSOC process.  The number of processes are also determined by the number of pooling instances committed to each Map Service.  So counting the memory currently used by your Map Services and comparing it with the Memory available on the server should give you a rough estimation of how many more map services you can create and add.

So look at optimizing your existing services first:

Tuning and configuring services—Documentation | ArcGIS for Server 

Problem: The number of ArcSOC instances causes ArcGIS for Server performance issues 

View solution in original post

11 Replies
DerekLaw
Esri Esteemed Contributor

Hi Tim,

This is a pretty complicated question to answer. The answer depends on a combination of the following factors:

- the hardware specs of your Server machine;

- the # of instances assigned to each of your web services;

- the # of machines that participate in your Server site;

You also mentioned using web maps and not using ArcGIS Online, so I guess you're using Portal for ArcGIS.

- Are they installed on the same machine? or two separate machines?

Other factors:

- the hardware specs of your Portal machine;

I'm sure I'm probably missing some other factors as well. I suggest you review this site,

Server Software Performance - GIS Wiki | The GIS Encyclopedia 

And please checkout this topic: Anticipating and accommodating users—Documentation (10.4) | ArcGIS for Server 

Hope this helps,

FC_Basson
MVP Regular Contributor

Like Derek Law‌ says, your server specs will determine the number of services you can run, especially the amount of memory available.

Looking at the processes in the Task Manager, you should take note of the Memory (Private Working Set) for each ArcSOC process.  The number of processes are also determined by the number of pooling instances committed to each Map Service.  So counting the memory currently used by your Map Services and comparing it with the Memory available on the server should give you a rough estimation of how many more map services you can create and add.

So look at optimizing your existing services first:

Tuning and configuring services—Documentation | ArcGIS for Server 

Problem: The number of ArcSOC instances causes ArcGIS for Server performance issues 

RandallWilliams
Esri Regular Contributor

Piggybacking on these comments:

First, check out this KB. It's helpful when you believe you have the resources to publish more services but are still limited:

Unable to publish new or start existing services when a large number of ArcSOC.exe processes are running

http://support.esri.com/technical-article/000001218

With regard to FC's comment, the commit charge is a function of both physical memory and virtual memory. I've seen issues where admins hamstring virtual memory in favor of hard disk space, which can limit the amount of physical memory the OS can address. When that happens, the number of SOCs that can be instantiated can be severely limited.

JonGarrido
New Contributor III

Hello,

A haven't clear if there is a final response to the question raised up in this topic. I'm on the need to publish more than 200 map services about animal species and it seems that I have reached a limit. I could checked that when I stop some of the services already published then I can continue publishing services....

I have checked as well the memory of the server and it's with only up to 5-15% of usage . 

Arcgis server 10.5

Window server 2008 R2 Enterprise

memory 16.0 GB

So . Is there any limit on the number of services that ArcGis server can manage?

KR

Jon

0 Kudos
RandallWilliams
Esri Regular Contributor

There's not a hard limit to Server per-se, but there can be a limit depending on the environment. Also, the number of services isn't really the question - the issue is the number of service instances that are spun up (default is Min 1 Max 2). That's why you can publish and start more services if you stop some of the existing ones.

There's two ways to approach this situation. One is to alter your service design, the other is to alter the environment. 

I'm not sure what your end goal is, but personally, in terms of organization, I'd create a map document, say, for 'birds'. In that map document, I'd create sublayers for different species of birds. Then in your application, you can reference the individual feature layers as you need them. You may already be doing something similar, and this will result in a lower number of service instances running on your machine. I'd then have services for 'birds', 'monkeys', 'snakes', or whatever.

Outside of map design, I've seen two distinct environment issues come into play when publishing a large number of services to ArcGIS for Server. 

First, I'd check your virtual memory settings - ensure it's set to 'Windows managed' Hamstrung virtual memory can affect the amount of physical memory Windows can allocate to processes.

Sedcond, you may also want to check out this KB, it discusses the impact of the non-interactive desktop heap has on the number of services you can publish to a Windows machine. 

Finally, building up your stack and leveraging Portal for ArcGIS along with the ArcGIS Data Store will allow you to publish potentially thousands of feature layers without the overhead that ArcObjects based map services bring.

Hope that helps!

JonGarrido
New Contributor III

Thank you so much for your answer!!

Probably we will have to go through a redesign.... Sincerely not clear yet. We have a very large list of arthropods distribution maps. Some of them will be public, and some others will be private... . And it's interesting for the final users to have them in separate services....

Thank you again

KR

Jon

0 Kudos
RichardDaniels
Occasional Contributor III

Actually the minimum number of instances is 0 (1 is the default when you create a new service). If instances are set to zero you save a lot of memory with the trade off that there will be a delay as the instance starts the first time the service is accessed (over some time period, usually 10 seconds to 1 minute). Instances=0 is a good option when you have a large number of published feature services (think Open Data) but only a few of them are active at any one time.

 

Rich

MGPInc_
New Contributor

We were told by ESRI there is a physical limit on the number of service instances. Last year an ESRI Professional Services engineer told us that there is a limitation of around 200 instances per server. He described it that each service creates an application server which is similar to a desktop instance and Windows has limits how many there can be.

Is this true? Is there a difference between 10.2 and 10.5 ArcGIS Server in terms of the instance limits?

(let's assume RAM and CPU are not the limitation here)

Thank you!

0 Kudos
RandallWilliams
Esri Regular Contributor

The number of ArcSOC.exe instances that can be created on a given server is limited based on the value of the non-interactive desktop heap. This is specific to ArcObjects based services, like Map Services, GP services, etc.  There's not a difference between 10.2 and 10.6 in that regard. I've seen users squeeze out ~300 services before in the past, but again that all depends on what's going on in the background. If you deploy Portal for ArcGIS and publish hosted feature and hosted tiled services, those aren't ArcObjects based and are much more scalable.