Yeah, doesn’t look healthy. There’s a lot of results there. Counting the memory pressure events is easy, but the question I have is – how long do these events run? How long are we waiting for SQL Server / Windows resolves these memory pressure events?

In theory, that would be easy to calculate – stick a ROW_NUMBER on the output of the above query, and join with itself on the next event. (As we’re only interested in the event time and the type, we’ll discard the rest of the fields; and we’re only interested in the last 24 hours, hence the additional filter in the “OrderedBuffers” CTE):

Oh, that doesn’t look so good. 31k seconds is, what, 8.5 hours of dealing with these events in a day?

I absent-mindedly re-ran the query:

What now? A different result? A radically different result? I mean, it’s a better result but the fact that the number has changed and by such a huge amount means that there’s something obviously very wrong with my thinking. What could it be?

Time to get down and dirty with the actual contents of the Ring Buffer to see what’s actually there. Just a quick adjustment to the original query to return the whole XML field:

If you’ve been paying attention, you’ll have noticed that I’ve done the rownumbering in reverse order, and added a dummy (RowNum 0) field at the top of the list – this is to make sure that, if the most recent record is a RESOURCE_MEMPHYSICAL_LOW record, that we can get results that include that value.

This all looks OK in theory. But we’re still getting stupidly high values for the SecondsPressure field, and wait – what’s this? Multiple ring buffer records with the same ID?

Something else isn’t right. Time to properly look at the XML.

Re-run the previous query, and you’ll notice that the XML is underlined – click on it in SSMS, and it’ll open up in a new window, neatly formatted and readable by humans. If you compare and contrast a couple of records with the same ID, you’ll notice that they have different MemoryNodeIDs – and we haven’t taken that into account.