
Originally Posted by
Soulfish
I'd also look at if you really need to run 4 vCPU for the VM. As @
kmount says you may find that your issue is CPU contention. If the VM is unable to schedule all 4 vCPU to physical CPU cores simultaneously it will have to wait until the hypervisor can get 4 physical cores. This can cause very bursty performance issues when it looks like your VMs should be running just fine.
To be perfectly honest most VMs run fine with 1 vCPU, or 2 at a push. Very very rarely do you ever need more. Much better to start small with VMs and get bigger if you are being resource constrained then to do the opposite

Good point - you need to check if your SQL schedulers have a backlog.
Here's a bit of SQL code (not mine, picked it up from my travels on the net, credits to OP) that show two crucial items of importance for each of your SQL schedulers:
Current_task_count and runnable_task_count.
An SQL task that is in a 'runnable' state means that it is ready to go but cannot yet be serviced by an SQL scheduler. If the runnable_task_count is more than 0, this is a backlog and indicates that, at the time the query was run, there were jobs waiting but couldn't be serviced.
Code:
--If you are seeing lots of SOS_SCHEDULER_YIELD in your Wait States, that is a very stong indicator of CPU pressure.
-- You can run the DMV query to confirm that:
-- Check SQL Server Schedulers to see if they are waiting on CPU
SELECT scheduler_id, current_tasks_count, runnable_tasks_count
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255
--If you see the runnable tasks count above zero, that is cause for concern, and if you see it in double digits for any length of time, that is cause for extreme concern!