• State Suggested Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 13924 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Core Memory

Emte
over 6 years ago

Looking to start a discussion on Core memory usage and memory trouble-shooting in general

1) The first problem we are seeing is that the Core will often be at 0 free memory with a HUGE amount in standby. Yes I know low free memory is "normal" in current server OS's and that standby memory is available to be used by another application if it needs it. But that is certainly not my experience either and def not when RR is the one with all the memory in standby

I have a Core that has 125GB of memory, 25GB is in use from every process and 100GB is in standby. 0 Free

I see the TN below about write caching. But a few issues

https://support.quest.com/rapid-recovery/kb/119686/high-paged-pool-ram-utilization-on-systems-running-appassure-or-rapid-recovery

a) The Core is 2012 R2 so should not be having this issue.

b) The technote gives no indications of how to confirm if you are having this issue.

c) Without a way to confirm if I am having this issue, the technote may not even help

https://www.quest.com/community/products/rapid-recovery/f/forum/21016/core-memory-usage-in-hyper-v-vms-making-vms-unresponsive#

 

2) Rammap file summary will often show a HUGE amount (+100GB) of memory in standby

Is this normal, does it show a problem with write cache (or anything else)

Why does this memory only show up in RAMMAP file sumary and point to the dfs.records file of our repo.

What does it not show up as standby memory allocated to core.service.exe (or any process) in task manager/ resource monitor. This is not how process are supposed to act

Parents
  • 0 over 5 years ago
    That KB article is like 4+ years old and I should probably go back and review and rewrite it (although that version of the software is EOL). Yes, I believe that the issue was Windows ability to reclaim standby memory in 2008. So since we can't improve Windows, we avoid the situation by removing write caching which absolutely is responsible for large quantities of standby memory. I don't remember if it showed up as high page pooled. I'm pretty sure it didn't, but frankly, without installing the old build and testing it out, I can't tell you for sure one way or another.

    I'm not saying that disabling write caching is not worth trying. If you have a server with performance issues and high standby memory, I'd absolutely try disabling write caching. We have seen it help on 2012 servers in some situations. We still haven't isolated exactly why it helps, but usually it helps on core servers with lots of agents and lots of jobs occurring. I personally believe it has to correlate with Windows write caching not being able to keep up and swap the memory as fast as it should and if you simply force Windows to pass the write over to the storage immediately you usually get the benefit of controller or disk caching on the storage and that is faster than Windows for sure. Essentially you remove a layer of data processing by removing the write caching option and that can speed things up. On systems where you don't have controller or disk caching (like a CIFS repo) you might see improvement in speeds when write caching is enabled vs. when it is disabled. But like I said, that's a hunch straight from my gut and not necessarily based on any specific testing I've seen done.

    I agree, it would be nice if Windows showed with what files the pages in standby RAM coincide.
Reply
  • 0 over 5 years ago
    That KB article is like 4+ years old and I should probably go back and review and rewrite it (although that version of the software is EOL). Yes, I believe that the issue was Windows ability to reclaim standby memory in 2008. So since we can't improve Windows, we avoid the situation by removing write caching which absolutely is responsible for large quantities of standby memory. I don't remember if it showed up as high page pooled. I'm pretty sure it didn't, but frankly, without installing the old build and testing it out, I can't tell you for sure one way or another.

    I'm not saying that disabling write caching is not worth trying. If you have a server with performance issues and high standby memory, I'd absolutely try disabling write caching. We have seen it help on 2012 servers in some situations. We still haven't isolated exactly why it helps, but usually it helps on core servers with lots of agents and lots of jobs occurring. I personally believe it has to correlate with Windows write caching not being able to keep up and swap the memory as fast as it should and if you simply force Windows to pass the write over to the storage immediately you usually get the benefit of controller or disk caching on the storage and that is faster than Windows for sure. Essentially you remove a layer of data processing by removing the write caching option and that can speed things up. On systems where you don't have controller or disk caching (like a CIFS repo) you might see improvement in speeds when write caching is enabled vs. when it is disabled. But like I said, that's a hunch straight from my gut and not necessarily based on any specific testing I've seen done.

    I agree, it would be nice if Windows showed with what files the pages in standby RAM coincide.
Children
No Data