Update Subnetwork tool takes long time intermittently

[EstherSmith_Dev]

Hi,

We are Electricity Distribution utility and using UNM model in ArcGIS Enterprise 10.9.1. 

We intermittently see geoprocessing Tool for Update Subnetwork taking really long time in ArcGIS Pro 3.3.1 for a single subnetwork, when editing network in a non-default version. Under normal conditions, it takes ~30-60 seconds per subnetwork while in a non-default version. But at times it takes 30-60 minutes for one subnetwork. CPU, memory and GPU on ArcGIS Pro machine is under-utilized. Also, we see no evidence of UNM UpdateSubnetwork operation being called in ArcGIS Server log while Pro tool is in the executing status. 

Question is, does Update Subnetwork while in a non-default version happen purely as ArcGIS Pro calculation and not use REST API? What can contribute to really slow performance?

Thanks,

Vish

[EstherSmith_Dev]

Forgot to mention Update Subnetwork in both Default and named versions are defined to be without eventing.

[gis_KIWI4]

Hi @EstherSmith_Dev , 

If you are using Enterprise then it should via the service.
The duration of the update subnetwork operation could be due to the number of records in the subnetwork but even then 30 to 60 mins sounds too much.

You mentioned that " CPU, memory and GPU on ArcGIS Pro machine is under-utilized." is it the same on the server running the service? 

If server is not resource constrained then another thing to check in the logs is if the process is actually finished but ArcPro is somehow not getting the message it's done. If you haven't already change the logging level to verbose to see if there are any messages you may not have caught before. 

[SamDeLore]

Hi @EstherSmith_Dev,

Have you checked the logs for the UN service itself? I've noticed similar where it can be difficult to track down logs of what's happening, there are no Jobs in the server logs, but I can see the process running on the UN service logs for our deployment.

In terms of performance, for us at least, large subnetworks with lots of loops and not many directional devices = exponential increase in processing time. I'm talking 12 hours for our largest one which we'll address with some additional terminal assignments.

I've never seen a hardware constraint on update subnetwork though, only instance count, I've never monitored SQL while running it though 🤔