• State Suggested Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 13930 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

    Hi Emte:

    If I understand correctly, there seems to be some misunderstanding (how's that as a lame pun) between the way Rapid Recovery manages cached memory and standby memory. There some connection between the two but it is on the Windows side and daresay,  it even makes some sense.

    To clarify, I suggest an experiment.

    Open the Resource monitor and set it on the memory tab.

    Open Regedit and make sure that the WriteCaching Policy is set to 2. Take a snapshot or a small base image to get the Standby Memory running. When all is done, you get something like below:

    Once no jobs are

    When no jobs are running, restart the core service. When the core service comes back and all the related tasks finish, you get something like below:

    Please note that during the service restart process, the Standby memory changed very little if at all. The main memory variations were related to the used memory (green) which changed quite a bit, first being released, then being re-allocated at the time the service finished restarting and after that by Windows memory caching allocations.

    Now, change the WriteCachingPolicy to 3 and restart the core service without touching anything else.

    You get something like this:

    If you monitor the operation you will see that the standby memory remains constant until the core service finishes all service restart related jobs. (Reason for the hard faults as well)

    The total memory used by Rapid Recovery has decreased due to caching being not managed by Windows. At the same time a significant part of the Standby memory (which was not touched) was suddenly released (I guess at the time Windows 'notices' that it does not managing the Rapid Recovery Cache Policy anymore).

    The explanation is that Memory that was cached by Windows before being flushed into the repository continued to be kept 'at hand' as standby memory. Once Windows caching is not used anymore, the need for that standby memory goes away and as such it is released.

    However, over time, other I/O operations may increase the standby memory usage.

    Again, the Standby Memory per se is a positive Windows feature as long as it is properly released when needed -- a process that was significantly improved in Windows 2012R2 and 2016.

    However, as stated before, the Standby Memory, which was designed for small files manipulations, does not help deduplicated backups too much -- there are too few reusable blocks hosted in the Standby Memory to have a significant performance impact (but it does not do any harm either).  

Reply
  • 0 over 5 years ago

    Hi Emte:

    If I understand correctly, there seems to be some misunderstanding (how's that as a lame pun) between the way Rapid Recovery manages cached memory and standby memory. There some connection between the two but it is on the Windows side and daresay,  it even makes some sense.

    To clarify, I suggest an experiment.

    Open the Resource monitor and set it on the memory tab.

    Open Regedit and make sure that the WriteCaching Policy is set to 2. Take a snapshot or a small base image to get the Standby Memory running. When all is done, you get something like below:

    Once no jobs are

    When no jobs are running, restart the core service. When the core service comes back and all the related tasks finish, you get something like below:

    Please note that during the service restart process, the Standby memory changed very little if at all. The main memory variations were related to the used memory (green) which changed quite a bit, first being released, then being re-allocated at the time the service finished restarting and after that by Windows memory caching allocations.

    Now, change the WriteCachingPolicy to 3 and restart the core service without touching anything else.

    You get something like this:

    If you monitor the operation you will see that the standby memory remains constant until the core service finishes all service restart related jobs. (Reason for the hard faults as well)

    The total memory used by Rapid Recovery has decreased due to caching being not managed by Windows. At the same time a significant part of the Standby memory (which was not touched) was suddenly released (I guess at the time Windows 'notices' that it does not managing the Rapid Recovery Cache Policy anymore).

    The explanation is that Memory that was cached by Windows before being flushed into the repository continued to be kept 'at hand' as standby memory. Once Windows caching is not used anymore, the need for that standby memory goes away and as such it is released.

    However, over time, other I/O operations may increase the standby memory usage.

    Again, the Standby Memory per se is a positive Windows feature as long as it is properly released when needed -- a process that was significantly improved in Windows 2012R2 and 2016.

    However, as stated before, the Standby Memory, which was designed for small files manipulations, does not help deduplicated backups too much -- there are too few reusable blocks hosted in the Standby Memory to have a significant performance impact (but it does not do any harm either).  

Children
No Data