Core Memory

I could be way off here, but I thought that standby memory is managed by windows and the whole point of standby memory is to allow Windows to try and "cache" pages that are no longer actively needed by a process. The intent of keeping it in RAM marked as inactive rather than zero it out, is to better server the processes running on the system that are using lots of pages of RAM. So for processes that are using the same pages over and over but are deallocating memory regularly, Windows is speeding that applications data processing time by "caching" those pages so that it doesn't have to call them from the disk when the process needs them again.

The reason the RR repository files are the ones that are making up most of the standby RAM is that when write caching is enabled on a repository, RR allows Windows to cache writes to the repository in RAM. So lots and lots of pages of RAM are consumed by writes to those files and then marked as inactive once the write is complete. Over time you see standby memory grow to consume all RAM since Windows is leaving those pages in Standby and not zeroing them out to try and improve performance. More than likely it isn't improving performance because RR is a backup software so most of what it does is data writes to the repository. Reads only happen for tasks like replication, virtual standby, data checks, rollup, etc. So unless those tasks are happening immediately after a backup completes, standby memory is probably not improving performance.

The KB article 119686 was written specifically for Server 2008 and 2008 R2 which both had issues with quickly releasing standby RAM. Windows memory manager didn't handle standby memory as efficiently as Server 2012 and newer do, and so when the system reached 0% RAM free due to active and standby memory, we saw performance degrade. We believe it has something to do with Windows Memory manager not being able to zero a page and return it to another process efficiently. By disabling write caching, Windows doesn't fill the standby memory with cached pages from the repository writes and doesn't end up in a situation where it is completely out of free memory and has to zero out standby memory to make it available to other processes.

That said, in 2012 and newer we have seen negligible difference between write caching enabled and disabled in the core software. Again, because RR does mostly data ingest (since it's a backup software and that's its primary purpose), it doesn't take long for Windows to run out of readily available RAM for write caching. Especially when you have 3 or 4 concurrent backup jobs sending data to the core and maxing out resources. So if you're unhappy with all your RAM being in standy, disable write caching in the repository per that KB article and I'll bet you see significantly less RAM marked as Standby.

I could be way off here, but I thought that standby memory is managed by windows and the whole point of standby memory is to allow Windows to try and "cache" pages that are no longer actively needed by a process. The intent of keeping it in RAM marked as inactive rather than zero it out, is to better server the processes running on the system that are using lots of pages of RAM. So for processes that are using the same pages over and over but are deallocating memory regularly, Windows is speeding that applications data processing time by "caching" those pages so that it doesn't have to call them from the disk when the process needs them again.

The reason the RR repository files are the ones that are making up most of the standby RAM is that when write caching is enabled on a repository, RR allows Windows to cache writes to the repository in RAM. So lots and lots of pages of RAM are consumed by writes to those files and then marked as inactive once the write is complete. Over time you see standby memory grow to consume all RAM since Windows is leaving those pages in Standby and not zeroing them out to try and improve performance. More than likely it isn't improving performance because RR is a backup software so most of what it does is data writes to the repository. Reads only happen for tasks like replication, virtual standby, data checks, rollup, etc. So unless those tasks are happening immediately after a backup completes, standby memory is probably not improving performance.

The KB article 119686 was written specifically for Server 2008 and 2008 R2 which both had issues with quickly releasing standby RAM. Windows memory manager didn't handle standby memory as efficiently as Server 2012 and newer do, and so when the system reached 0% RAM free due to active and standby memory, we saw performance degrade. We believe it has something to do with Windows Memory manager not being able to zero a page and return it to another process efficiently. By disabling write caching, Windows doesn't fill the standby memory with cached pages from the repository writes and doesn't end up in a situation where it is completely out of free memory and has to zero out standby memory to make it available to other processes.

That said, in 2012 and newer we have seen negligible difference between write caching enabled and disabled in the core software. Again, because RR does mostly data ingest (since it's a backup software and that's its primary purpose), it doesn't take long for Windows to run out of readily available RAM for write caching. Especially when you have 3 or 4 concurrent backup jobs sending data to the core and maxing out resources. So if you're unhappy with all your RAM being in standy, disable write caching in the repository per that KB article and I'll bet you see significantly less RAM marked as Standby.