Hi, I have a use case where we need to run multiple instances of Ganesha on Kubernetes. To better understand our performance envelope and boundaries to plan the deployment better, I need to understand the lowest amount of memory Ganesha requires in theory to operate sufficiently without being reaped by the oom killer. Setting the limit extremely low, like in the hundred of megabytes, almost instantly kills Ganesha when applying pressure. I'd appreciate any pointers or configuration options to consider. Regards Michael
This isn't a question that can be answered, really. We can tell you how much memory a particular version of ganesha uses on a particular machine under no load at startup, but the majority of memory used by Ganesha is used under load, so the amount of memory used depends entirely on the workload being run. You'll have to work that one out for each workload you care about. Daniel On 7/6/22 13:55, michael.mattsson@gmail.com wrote:
Hi, I have a use case where we need to run multiple instances of Ganesha on Kubernetes. To better understand our performance envelope and boundaries to plan the deployment better, I need to understand the lowest amount of memory Ganesha requires in theory to operate sufficiently without being reaped by the oom killer. Setting the limit extremely low, like in the hundred of megabytes, almost instantly kills Ganesha when applying pressure.
I'd appreciate any pointers or configuration options to consider.
Regards Michael _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
For what it's worth, we are working on an mdcache LRU redesign that will allow Ganesha to be much more successful in reaping entries and thus more likely to stay within the mdcache size bounds configured. However, that limit is never a hard limit, so Ganesha COULD still exceed it. The redesign though may allow us to consider how to implement a hard limit. Beyond this, Ganesha does have one other significant unbound memory use - state such as byte range locks, share reservations (NLM or NFSv4 OPEN), delegations, and layouts. These tend to use less memory and I have yet to see a workload that created significant memory use there compared to the mdcache. Beyond that, there are a few other unbound memory allocations, however, they are mostly transient, and even smaller in comparison to mdcache and state, however, a peak in workload could conceivably grow one of those large enough. In the meantime, sizing your mdcache to your workload and making sure you don't have too many threads configured (we have seen admins setting up with 10,000 threads) should work to keep memory manageable. Frank
-----Original Message----- From: Daniel Gryniewicz [mailto:dang@redhat.com] Sent: Wednesday, July 6, 2022 11:08 AM To: support@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Support] Re: Minimum memory requirements
This isn't a question that can be answered, really. We can tell you how much memory a particular version of ganesha uses on a particular machine under no load at startup, but the majority of memory used by Ganesha is used under load, so the amount of memory used depends entirely on the workload being run. You'll have to work that one out for each workload you care about.
Daniel
Hi, I have a use case where we need to run multiple instances of Ganesha on Kubernetes. To better understand our performance envelope and boundaries to
On 7/6/22 13:55, michael.mattsson@gmail.com wrote: plan the deployment better, I need to understand the lowest amount of memory Ganesha requires in theory to operate sufficiently without being reaped by the oom killer. Setting the limit extremely low, like in the hundred of megabytes, almost instantly kills Ganesha when applying pressure.
I'd appreciate any pointers or configuration options to consider.
Regards Michael _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
_______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
Hi, Thank you for your thoughtful response. I will take this into consideration when analyzing the performance and outcomes. In our situation, a hard limit would be ideal for predictability, so I'll be on the lookout for that. ;-) Regards Michael
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
michael.mattsson＠gmail.com