Understanding the Diagnostic Monitor and performance issues

[FranziskaSumpf]

Hello, I am looking for some help on how to interpret the Log in the Diagnostic Monitor. I frequently experience lags and slow performance, so I had a look at the Diagnostic Monitor, but I don't understand what it is telling me.

What I see a lot is "CSharedQueue Stall timeout", often several in a row (up to 40 or 50!), which can take up to a minute, combined. Any clues what this is?

Another thing I noticed is, that AGP often seems to be accessing data that are not in any open map. I have observed this in several projects, actually.

The problem with this is, that some data are on network drives that are painstakingly slow, especially when accessed through our VPN when working from home. E. g. in the screenshot above it is an elevation raster on the X drive. I know that network drives and AGP don't go together well, but that is how my organisation provides our base layers. I have my own data and projects saved locally and avoid tasks that need layers from the network drive when working from home. This approach worked well in the past.

But it seems to go beyond unnecessary data access: Today I was amazed to see the log fill up with entries related to layer drawing, symbol drawing and label drawing. No map was open! Why did AGP draw one – or maybe even several? If I filter for any specific layer I get 10 instances each of Beginning of layer draw and End of layer draw. Did AGP just draw every layer in every map in the project, even though they where closed?

What I actually tried to do was create a new (empty) map. I had closed the one that was still open, so that only a catalog view remained, and then used the right-click-menu in the catalog pane to create the new map. It took AGP 5 minutes to get it done! But only the last few entries in the log seem to be related to this.

Am I completely misunderstanding the log? Is there any documentation for the Diagnostic Monitor (I searched, but couldn't find anything). Any help is appreciated!

Currently using version 3.5.2 with a concurrent use license
(but I checked the http tab and all entries seemed to be related to getting a basemap (which I did not need, as no map was open), and not to the licence manager).

[DanPatterson]

Did you see this?

Diagnostic Monitor—ArcGIS Pro | Documentation

may not be indepth enough for your needs

[FranziskaSumpf]

Yes, I looked at it. But it only explains the tabs, not the output.

[DanPatterson]

I don't see anything easier.  It seems that rather than explain the outputs, they put their efforts on how to improve performance under a variety of conditions

Troubleshooting Performance Issues in ArcGIS Pro

the most obvious being work with locally stored data (obviously not possible for many)

Tech support may point you to other materials.

Good luck. 

[FranziskaSumpf]

That's what I'm trying to do (working locally) for the most part. But it seems AGP still accesses data in the background, even if I do not have them in any open map, which is kind of counterproductive – at least that is how I understand those log entries.

[Robert_LeClair]

Agree that a call to Esri Support Services is likely the best use of time to learn what the screen grabs mean.  found a few items from the web but no central repository of what the output information means.

The Main CIM worker thread in ArcGIS Pro is a specialized thread used to access the geodatabase. It is part of the application's multithreaded architecture, allowing for the separation of the user interface from the worker threads. This means that while the user can interact with the application, tasks that require database access can run on the Main CIM worker thread. This thread is essential for maintaining the CIM state and ensuring that changes to the application state are synchronized across all CIM threads.

The Aux CIM worker thread refers to one of the four CIM threads in ArcGIS Pro, specifically designed for drawing and performing background operations. These threads are part of the Cartographic Information Model (CIM), which manages the configuration state of the currently loaded project. The auxiliary threads help accelerate map rendering and handle tasks that do not depend on the CIM state, allowing for efficient operation within the application.

The CSharedQueue Stall Timeout issue in ArcGIS Pro often indicates performance bottlenecks or timeouts during operations, particularly when working with large datasets, cloud storage, or virtual environments. This can result in delays, unresponsiveness, or failed tasks.

CIM Resources · Esri/arcgis-pro-sdk Wiki · GitHub

[FranziskaSumpf]

Thanks for the explanation of the threads. I think I've not fully understood it yet, but I'm getting there 😄

The CSharedQueue Stall Timeout issue in ArcGIS Pro often indicates performance bottlenecks or timeouts during operations, particularly when working with large datasets, cloud storage, or virtual environments. This can result in delays, unresponsiveness, or failed tasks.

---

I would not consider my own datasets large, but some of the external ones probably are. We don't have virtual environments (I think), but if network drives qualify as cloud storage then that's most likely my bottleneck. Too bad the CSharedQueue Stall Timeout doesn't include more information (what exactly caused the timeout).

With the github I'm out of my depths, I'm afraid. But there's always room to improve and learn (starting with understanding github itself, I suppose).

[jorisfrenkel]

Although in my organization we have a different setup, we also experience slow performance when working with large projects that contain a number of maps and lots of layers, even when the maps are closed. So it doesn't surprise me that you experience these kind of problems, more so because of the setup you (are forced to) use.

When users have these issues, we always recommend to start with a new, clean project, or with a template project with the layers they often need. 

[FranziskaSumpf]

Would rebuilding the project help if I end up with basically the same project? All my maps and layers are there for a reason (I have already anything out I don't need regularly).

It would take me quite long, to set everything up again and relink all data (layers have charts, joins and relates, definition queries, multiple label classes; some projects have notebooks or custom tools, some have layouts that would take long to rebuild... you get the idea)

[jorisfrenkel]

No, I wouldn't do that. Only if you can split up projects so that they end up significantly smaller. 

I would try to split up the projects if possible.

If you uncheck the layers in the maps that show the drawing actions in the log, do they still appear as being drawn? Of course then also uncheck the layers on your network drives that you don't use at home.

Joins and relates are also a drag on performance, according to the document about troubleshooting performance, referred to above. ESRI suggests saving them as new feature classes.