deepakarumugam.s@nutanix.com has uploaded this change for review.
Limit the number of files we delegate
Today each delegation state places a refcnt
on a mdcache entry.Ganesha can therefore only
release this mdcache entry - when this
delegation state is destroyed.
A delegation state can only be destroyed when,
(1) Client id expires
(2) Some other client tries to do
write style operations on the file
(3) Client voluntarily returns the delegation
So if you have a scenario where active clients
are mostly reading a bunch of files from the
server - today we have to wait on the client
to voluntarily return the delegation before
we can release the corresponding mdcache entry.
Typically linux clients (this was tested using
some flavor of centos7) return delegations on
unused files within seconds to minutes. But
what was seen was that even if the application
on the client side is continuosly
stating a file we donot return the delegation.
When this is done at scale we end up with
OOMs on the server because the mdcache entries
corresponding to the delegated files cannot be
released.
One could argue that we should instead do a
delegation recall as part of the mdcache
reaper or some other reaper - which can be
helpful but that still puts the server
in the good grace of the clients.
Therefore would like to introduce a limit
on the number of files we delegate - which
can be helpful in tuning the server memory
usage in scenarios like above.
Tested this change with pynfs based tests that
get delegations on a bunch of files and never
return it
Change-Id: I092e47cec176dcbb191c28b98e8fa897304ba173
Signed-off-by: Deepak Arumugam Sankara Subramanian <deepakarumugam.s@nutanix.com>
---
M src/SAL/state_deleg.c
M src/include/gsh_config.h
M src/support/nfs_read_conf.c
3 files changed, 23 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/18/1198218/1
To view, visit change 1198218. To unsubscribe, or for help writing mail filters, visit settings.