• State Suggested Answer
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 26 subscribers
  • Views 13932 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 6 years ago
    Thanks Tudor, I appreciate the feedback but that seems to create more questions about this issue than it answers.

    "The issue with Rapid Recovery is that due to deduplication there are relatively few blocks reused so the standby memory is largely useless. "

    A Core I am working on has 128GB of memory, 100GB is in standby and there is 0 free.

    The first issue is that 97GB of standby is taken up by the dfs-records, dfsrecords_ids file (according to file summary from rammap) So RR is the one eating up all my standby memory

    The second issue seems to be that whatever RR is doing with this 97 GB of memory is not recorded correctly. And by that I mean that no where in Task Manager or Resource Monitor can you make the correlation that the Rapid Recovery is the one who has all this memory in standby. It is only by looking at rammap that you can see this. Not a huge issue but also certainly not a best practice as far as MS is concerned

    The Core in question has some other issues with it but I have been bouncing around on a few Cores and I see the same thing on almost all of them. My local test Core is running 0 jobs and it still has 12 GB of standby memory (dfs.record's files) on a VM with only 16GB


    A follow up would be the technote

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

    Task Manager on the production Core shows 10 GB in paged pool and 9 7GB cached. My lab Core shows 400 MB in paged pool and 12 GB cached. The production Core is VERY busy and falling behind, so it is certainly possible that it is encountering the issue described but my Core looks very similar and it has not ran a singe job for hours.

    Both Cores are 2012 R2 and the paged pool memory usage is not high. So it would seem like the technote above is not a great solution. But of course it maybe that the technote was just not clearly written (it does mention cached later in the TN)

    And if it is a good solution to the production Core that is falling behind. What would you recommend I look at for my core that is doing nothing but has a similar issue?
Reply
  • 0 over 6 years ago
    Thanks Tudor, I appreciate the feedback but that seems to create more questions about this issue than it answers.

    "The issue with Rapid Recovery is that due to deduplication there are relatively few blocks reused so the standby memory is largely useless. "

    A Core I am working on has 128GB of memory, 100GB is in standby and there is 0 free.

    The first issue is that 97GB of standby is taken up by the dfs-records, dfsrecords_ids file (according to file summary from rammap) So RR is the one eating up all my standby memory

    The second issue seems to be that whatever RR is doing with this 97 GB of memory is not recorded correctly. And by that I mean that no where in Task Manager or Resource Monitor can you make the correlation that the Rapid Recovery is the one who has all this memory in standby. It is only by looking at rammap that you can see this. Not a huge issue but also certainly not a best practice as far as MS is concerned

    The Core in question has some other issues with it but I have been bouncing around on a few Cores and I see the same thing on almost all of them. My local test Core is running 0 jobs and it still has 12 GB of standby memory (dfs.record's files) on a VM with only 16GB


    A follow up would be the technote

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

    Task Manager on the production Core shows 10 GB in paged pool and 9 7GB cached. My lab Core shows 400 MB in paged pool and 12 GB cached. The production Core is VERY busy and falling behind, so it is certainly possible that it is encountering the issue described but my Core looks very similar and it has not ran a singe job for hours.

    Both Cores are 2012 R2 and the paged pool memory usage is not high. So it would seem like the technote above is not a great solution. But of course it maybe that the technote was just not clearly written (it does mention cached later in the TN)

    And if it is a good solution to the production Core that is falling behind. What would you recommend I look at for my core that is doing nothing but has a similar issue?
Children
No Data