nfs server resource exhaustion (before it's too late)

Rick Macklem rmacklem at uoguelph.ca
Tue May 19 15:29:48 UTC 2009


In the experimental nfs server (sys/fs/nfsserver), there is a function that,
when it returns non-zero, causes the server to reply NFSERR_DELAY to the
client so that it will try the RPC again a little later. (Or, for NFSv2 over
UDP, which doesn't have NFSERR_DELAY, it simply drops the request and assumes
the client will timeout and try it again.) This is intended to avoid the
situation where the server cannot m_get/m_getcl/malloc part way through
processing a request, due to resource exhaustion. (The malloc case isn't
as critical, since I have high water marks set to limit the # of allocations
for the various NFSv4 state related structures that are malloc'd.)

At this point the function is just a stub:
int
nfsrv_mallocmget_limit(void)
{

 	return (0);
}

I just took a quick look (I don't know anything about UMA, except that it
seems to be used by m_get and m_getcl) and this was what I could think of
for doing the above on FreeBSD8. (It wasn't obvious to me if there
was a limit set for the various zones used by malloc(), so I didn't
include them.

int
nfsrv_mallocmget_limit(void)
{
 	u_int32_t pages, maxpages;

 	uma_zone_get_pagecnts(zone_clust, &pages, &maxpages);
 	if (maxpages != 0 && (pages * 12 / 10) > maxpages)
 		return (1);
 	return (0);
}

At this point, the only function I could see that would return the above
information is sysctl_vm_zone_stats() and it looks like overkill. Also,
the function needs to be relatively low overhead, since it is called for
every nfs rpc the server gets so I thought this might be ok?
/* added to sys/vm/uma_core.c */
void
uma_zone_get_pagecnts(uma_zone_t zone, u_int32_t *pages, u_int32_t *maxpages)
{
 	uma_keg_t keg;

 	ZONE_LOCK(zone);
 	keg = zone_first_keg(zone);
 	*pages = keg->uk_pages;
 	*maxpages = keg->uk_maxpages;
 	ZONE_UNLOCK(zone);
}

Does this look reasonable or can anyone suggest a better alternative?

Thanks in advance for any suggestions, rick



More information about the freebsd-arch mailing list