How to troubleshoot suspended queries in Azure Synapse?

Question

Currently, I encounter an issue of suspended queries in Azure Synapse when executing from ADF (Store procedures call). Also, I followed the suggestion in the link below for troubleshooting the issue:

Delete due to sensitive informations

The troubleshoot queries returned as below:

I checked if the transaction lock is the issue as I killed a few suspending or running queries which they ran for more than 15 hours. I also checked for the rest of the queries running but there is nothing would cause the transaction lock. I tried to run the store procedure manually from Azure Data Studio which is blocked as mentioned above and It took 40 seconds to complete. While the suspending query from ADF, it took nearly an hour to finish.

Any suggestion to troubleshoot this issue is much appreciated.

Thanks

Answer 1

There a number of factors you must always consider when tuning queries in Azure Synapse Analytics, dedicated SQL pools:

1. DWU - what DWU is your pool at? Lower DWUs mean lower concurrent users and lower performance and should not be used for any kind of performance tuning. Crank it up temporarily to rule this out as a problem, bearing in mind changing this disconnects any active queries. Also bear in mind, not all queries respond to higher DWU.
2. Resource class - what resource class is associated with the user executing these queries? Remember the default is smallrc , and the admin user always has smallrc . Understand static and dynamic resource classes . DMV sys.dm_pdw_exec_requests will give you useful information on this. Trial with your workload to find the sweetspot between performance and concurrency v resource class. Encourage your dev team to use labels in their queries: OPTION ( LABEL = 'some informative label' )
3. Table geometry - this is the distribution ( ROUND_ROBIN | HASH | REPLICATE ) of your table and the indexing choice ( CLUSTERED COLUMNSTORE | CLUSTERED INDEX | HEAP ). Clustered columnstore and round robin are the defaults but they are not always appropriate. Consider what is appropriate for your tables.

If you work through those and still have an issue you can start to look at statistics and workload classification for starters, but gather information on the points above should give you a good idea.

If you are just doing single value INSERTs, then don't. Dedicated SQL pools are terrible with these. Convert these to load from a file in a single INSERT / COPY INTO .