10:55 a.m.
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
11:08 a.m.
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(a)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(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org
11:40 a.m.
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(a)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
On 7/6/22 13:55, michael.mattsson(a)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(a)lists.nfs-ganesha.org To unsubscribe
> send an email to support-leave(a)lists.nfs-ganesha.org
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an
email to support-leave(a)lists.nfs-ganesha.org
4:43 p.m.
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
654
days inactive
654
days old
3 comments
3 participants
participants (3)
-
Daniel Gryniewicz -
Frank Filz -
michael.mattsson＠gmail.com