How to treat Severe ArcGIS Server Logs for System/DynamicMappingHost.MapServer?

[Yogesh_Chavan]

We are facing the below severe error logs on ArcGIS Server.

Trying to understand what could be triggering this or is there some ways to minimize/fix these errors?

Any help on this would be highly appreciated.

[JakeSkinner · Accepted solution]

Hi @Yogesh_Chavan, are you services configured with Shared or Dedicated instances? 

I've seen this error before when all services are configured with Shared.  Try changing the services to Dedicated.

https://enterprise.arcgis.com/en/server/latest/administer/windows/configure-service-instance-setting...

[Yogesh_Chavan]

Thank you @JakeSkinner for your insights.

We have 94 services on the server and very few are using the dedicated pool and all the others are on shared pooling.

Do we have to change pooling for all the services?

[JakeSkinner]

I would highly recommend the more frequently used services be switched to dedicated.  I typically only recommend a few services be set to shared instance type.

[berniejconnors]

I agree with @JakeSkinner.  We configure our map services in a similar way.  We reserve the use of shared instances for services we are quite certain will be used infrequently.  About 20 map services (or 25%) use the shared pool.

Bernie.

[DavidColey]

I would agree with both @JakeSkinner and @berniejconnors  - our Federated site is a 2 machine cluster, 8 cores each.  So for the site, I have the dynamic mapping service pooling set to 8 number of instances, giving me 16. But you shouldn't set the number of instances it can use to more than the number of cores you have.

So as a rule of thumb for the dynamic service, I would publish no more than 30 simple map services services to the shared instance.  In practice, I have about the same as Bernie, 15 -20 or so simple map image services.

As for the warning about the dynamic service crashing, I do not see that very often and since there is not much I can do about it, I just ignore it.  The service recovers and I move on.

I use Monitor, and for my any of my shared or dedicated instances, I can see the % saturation.  If I were to see one of my shared instances using up to like 75%, I would consider moving that instance to dedicated.  Otherwise, that might be or maybe could be the cause of the dynamic map service instance crashing. . .

[MattiasEkström]

@DavidColey @berniejconnors @JakeSkinner

You all agree that the number of services that use a shared pool should be just "a few" / 15-20 / 25 % / no more than 30. In the documentation I can't see anything that points to that, and the shared pool is used as default. For us, the shared pool was great to save resources on our server when it was introduced. A couple of months ago, we had 10.9.1 with about 100 services in the shared pool and 25 with dedicated, and it worked fine. But then we upgraded to 11.3 which seemed to go well at first, but then we noticed performance issues which came from "Instance of the service 'System/DynamicMappingHost.MapServer'" crashing all the time.

I've tried switching about 15-20 of the most used services in the shared pool to dedicated, so maybe we have about 80 in the shared pool and 45 with dedicated, but it didn't make any difference. Switching all except 20 services to dedicated would make the memory on our server run out.

We have a single server deployment of ArcGIS Enterprise on a virtual server with 4 cores (limited to that by our license) and 32 GB of memory.

Any suggestions?
We have a lot of services with just a few layers. Maybe I have to merge as many as I can to end up with a lower number of services but more layers in each service?

[JakeSkinner]

@MattiasEkström for any services that have relatively static data, I would recommend publishing them as hosted feature services.  Hosted feature services are very lightweight, and do not spin up any ArcSOC.exe processes.

[MattiasEkström]

Thanks @JakeSkinner 
I didn't know there is a performance benefint to hosted feature services, we have some relatively static data that I could publish as hosted feature services instead.