I did only:
--- linux-2.6.27.21/include/linux/sunrpc/auth.h 2009-03-23 23:04:09.000000000 +0100
+++ linux-2.6.27.21/include/linux/sunrpc/auth.h 2009-05-19 16:02:35.000000000 +0200
@@ -62,8 +62,12 @@
*/
- #define RPC_CREDCACHE_HASHBITS 4
+ #define RPC_CREDCACHE_HASHBITS 12
And i test it in prod since sunday: i only have 36% of one core used by
system
versus more than 3 cores used by system in another server that did a
drop_caches at morning...
OK, but it's still pretty bad. Let's tell the NFS guys.
In http://bugzilla.kernel.org/show_bug.cgi?id=14024 we appear to have a
major meltdown caused by the linear search in
rpcauth_lookup_credcache() with Yohan's workload.
OK. Could we please have some more details about the actual workload involved here?
I add a new server CPU graph and 60s readprofile on the bugzilla
As far as I can see, there is no RPCSEC_GSS involved, so credentials
should never expire. They will be reused as long as processes aren't
switching between thousands and thousands of different combinations of
uid, gid and groups.
My servers are imap servers.
Foreach user (~15 million) it have a specific uid over ~10 nfs netapp
storage.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
