Incidental
This is a long list that I haven’t had a change to dig through yet — all I did was compare them to which waits were occurring on my 2017 CU4 instance.
There are about 174 of them that I found, though some may just be generated by Hekaton that I don’t have set up on my home servers.
Feel free to make notes on that Google Sheet — I’ve opened that up to the public.
Some kind of interesting ones:
- BOOST_CPU_TASK
- CLOUD_FABRIC_ENQUEUE
- CLOUD_FABRIC_PAIRUP
- CLOUD_FABRIC_RELEASE_ALL
- CLOUD_FABRIC_WAIT
- CPU_ALLOCATION_VERIFIER
- FABRIC_PAIRING
- SOS_WORK_DISPATCHER
- TIERED_STORAGE_MIGRATION_TASK
- TIERED_STORAGE_PERSIST_LRU_INFO_TASK
- TIERED_STORAGE_REENCRYPTION_TASK
- TIERED_STORAGE_SCANNER
- WAIT_VLDB_DUMP_LOG_LOCK
I wonder what Microsoft considers a VLDB to be. Could this be the standard that we all abide by when talking about our VERY LARGE BIG HUGE TABLE problems?
Stay tuned!
1 Comment. Leave new
We see 96% of all waits that are SOS_WORK_DISPATCHER waits.
And we are on Azure Managed Instance.
SSMS Performance Dashboard ways there are excessive Waits on the server and we might be experiencing degradation of performance.