Starting with Microsoft SQL Server 2008 Service Pack 2 and Microsoft SQL Server 2008 R2 Service Pack 1, the non-yielding Resource Monitor message was extended to easily isolate the memory clerk that leads to the non-yielding condition.
The new message will resemble the following:
Resource Monitor (0x9b0) Worker 0x0000000003A2C1C0 appears to be non-yielding on Node Node_#. Memory freed: 0 KB. Last wait: lastwaittype. Last clerk: type clerk_type, name clerk_name. Approx CPU Used: kernel 0 ms, user 0 ms, Interval: Interval_value.
The following are descriptions of the various fields that are used in this message:
- Memory freed: This is how much memory is freed by Resource Monitor for the specified interval as measured in kilobytes. If the rate at which the memory is freed does not exceed 2 MB every five seconds, the Scheduler Monitor detects this condition as a non-yielding condition.
- Last wait: This is the last wait type for the Resource Monitor thread. You can use this field together with theApprox CPU Used field to identify whether the Resource Monitor thread is running or waiting for a significant part of the interval.
- Last clerk: This is the type and name of the memory clerk that was trimming its memory when the non-yielding condition occurred.
- Approx CPU Used: This is the kernel and user time that is used by Resource Monitor as measured in milliseconds. You can use this together with other fields to verify that Resource Monitor is making progress during the specified interval.
- Interval: This is the time that elapsed since the last clerk was notified as measured in milliseconds.
You can use this message in addition to the RING_BUFFER_RESOURCE_MONITOR entries from the time of the message to identify the source of the low memory notification.
For more information about how to interpret the RING_BUFFER_RESOURCE MONITOR. visit the following MSDN blog:
For more information about how SQL Server listens and responds to memory notifications and about the Resource Monitor task and troubleshooting memory-related performance issues in SQL Server, refer to the following MSDN blog articles:
