On Sat, Aug 20, 2011 at 12:03 AM, Doug Hughes <[email protected]> wrote: > Ah, I think I know exactly what this (above) is. Linux (CentOS) does not > fully implement the READDIRPLUS NFS RPC call, but Solaris does. When the > client asks for READDIRPLUS, the server fills in the packet with a large > number of replies and sends them in bulk. When the client asks for READDIR, > every single entry is enumerated as a single RPC which means 7000 RTTs. If > you are using ls -l or ls -color, automatically double that to 14000 RTTs > because it will be doing getxattr and/or stat calls for every entry. ouch!
What do you mean Linux doesn't fully implement READDIRPLUS? It works just fine for us and the behavior you describe is how it normally works. We've found that disabling READDIRPLUS in the mount options usually has a performance benefit in case the client doesn't really expect to read the whole directory for what it's doing. That depends on what the applications is doing. For instance, one dumb webmail client once asked for a full directory listing every time the user hit refresh in the website. Of course changing the webmail code was the best option but until then, letting it do a full directory scan on the server to satisfy the READDIRPLUS request was just too much for the storage server so we 'downgraded' to READDIR which allowed for better parallelization of disk resources on the server end. Solaris uses the DNLC facility for caching names and I suspect this could be another burden every time someone lists huge directories. It's probably between 128-256k and, while supporting a web hosting environment, I've routinely seen users with that many emails in their inboxes. That invalidates a lot of the cache and skyrockets disk I/O. The DTrace Toolkit has a script to check the DNLC cache but I suspect the Oracle support will have to request the OP to run it (due to warranty constraints). I'd be curious to see what Oracle Support discovers in this case. They've improved their service in the past year and it's common to see these problems escalated to their core engineering team. -- Giovanni Tirloni sysdroid.com _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
