Post reply

Resource Governor Classification Anomaly

  • December 20, 2022 at 3:36 pm

    #4128012

    So I've got this interesting situation that I can not find any documentation on.

    We have resource governor enabled, a classifier in place that appropriately assigns connections into workload groups.

    For example, user1 connects in, the classifier fires off and assigns user1 to WorkloadGroup-A

    Great!

    However, the strange part is... on occasion User1 will end up in the "Internal" workload group. Some might say "Impossible" but this is definitely happening and I believe its the source of some of our high CPU spikes that exceed the cpu cap set for the combined workload groups. (yes, we are setting cap_cpu_percent not just max)

    Wondering if anyone knows why the engine might take the reigns and essentially ignore the classifier and throw it in an unconstrained workload group only intended (to my knowledge) for core sql.

    I hope I have explained this well enough and appreciate any feedback and or thoughts in advance!

  • December 21, 2022 at 4:10 pm

    #4128514

    Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • December 21, 2022 at 4:18 pm

    #4128517

    Have you been able to verify that when this is happening the UserA session is indeed in workload group 1?

    Do you have any monitoring of sys.dm_exec_sessions when this happens to indeed verify that the session is not in the correct workload group?

    Are you able to reproduce the issue at all, as if it is indeed skipping the classifier function and going into the internal workload group it may sound like a potential code path bug and need reporting to MSFT via a support ticket.

  • December 22, 2022 at 3:32 pm

    #4128981

    So after doing some more digging, it looks like new connections come in and are part of the internal workload group initially before they are assigned to a user defined workload group. they aren't actually executing commands whilst in the the internal workload group. I guess the next step is to find out why the cap_cpu_percent seems to not hold everything down below the hard cap of 75%. We will see cpu spikes in the upper 90's sometimes and it even causes sql services to crash. The search continues.

     

    I appreciate the brain stimulating comment!

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply