Sql-server – High memory usage due to RING_BUFFER

The closest internal documentation I can find on the RM is from the PSS team here: How It Works: What are the RING_BUFFER_RESOURCE_MONITOR telling me?

Which specific to your question on which internal processes may contribute to changing the indicator there is no specific documentation that answers this...that I can find. The article references actually shows that there is a startup trace flag 8020 that can be used (with extreme caution) to narrow down what is triggering RM.

I think the main bit of text from the article above would be this:

There are memory broker decisions that come into play at this time. What the information is is saying is that a cache or the cache’s predicted usage will exceed internal targets and we need to start doing cache cleanup. By looking at the memory broker, ring buffer entries, you can see the behavior that broker it asking of RM. Using the clock hands you can see the internal and external hand movement. This will help you determine which caches are involved. The dbcc memorystatus() show good details and last notification states as well.

Not sure if that answers the question in full, but is about as close to what I can find online.

This is most likely caused by the MERGE operation in SQL Server being single threaded. No matter how many resources you throw at it, it wont run faster which is exactly what you are observing.

The solution is to manually parallelise the query by running multiple copies of the MERGE statement at the same time, each operating on their own subset of the data.

The problem is very common in data warehouses running SQL Server. There are a series of good design pattern in this document: http://technet.microsoft.com/en-us/library/dd425070(v=sql.100).aspx (DISCLAIMER: This is written by yours truly, so I am shamelessly plugging this)