I'm trying to understand memory stats a lot better and have been troubleshooting an issue with one of our SharePoint DB servers for a while now. Low PLE, frequent lazy writes, slow performance etc

I noticed today that the stolen memory counter was high, and remained high. It didn't really fluctuate.

My server has 16GB RAM and SQL Server is allocated a maximum 12GB. The stolen memory counter is around 8.5GB. Is that normal?

What could that be and how to pinpoint the cause? What should I be looking at?

SQL Server 2012 is patched to SP3.

UPDATE: Here's an output of a query of os_performance_counters showing the high Stolen Memory (high being relative to the max memory of 12GB given to SQL Server)

enter image description here


By looking at trend data in SCOM I can see that Stolen Memory has increased steadily over the last 120 days from 2GB to 8.5GB... this is really puzzling me.


  • 1
    It may also be useful to disclose how low the low PLE is. – Cody Konior May 15 '16 at 13:12
  • PLE dips as low as 3. Don't think it's a duplicate of that as this issue seems different, no spike in stolen memory, just a constant high of 8500mb – Molenpad May 15 '16 at 17:25
  • @Molenpad Is stolen memory 850 MB or as you mentioned in question 8.5 GB. Plus I said its possibly duplicate as in your question you seems like asking what is Stolen Memory. PLE rise and fall is in response to disk activity on your system. Its quite possible there are some queries running which is requesting lot of I/O hence forcing PLE to come down. – Shanky May 15 '16 at 18:12
  • 1
    Stolen memory refers to memory taken from buffer pool for sorting and hashing operations. Which means there are lot of queries running which are doing lot of sorting or may be using Hash join as an operator. From here it would require lots of data to actually see what is causing the issue. Is PLE really 91 ?, what query you used to calculate it. I guess you might be facing memory pressure I suggest add more RAM and increase max server memory value. – Shanky May 16 '16 at 9:15
  • 1
    @JimClouse No, the issue was never found but was perceived to be some bug in SharePoint. I moved jobs, which fixed the issue, at least for me :) – Molenpad Sep 27 '19 at 9:06