 | | | nfs slowness with ls - but why? | nfs slowness with ls - but why? 2006-02-15 - By David Spidley
Back
Thanks for your help so far:
> I would look in nfsstat to see how many stats etc are done by the
> commands. I am expecting that you are seeing something going on.. also
> look for the number of retries etc.
For an ls -l for 100 000 files, nfsstat shows:
Server rpc stats:
calls badcalls badauth badclnt xdrcall
1100847 0 0 0 0
Server nfs v2:
null getattr setattr root lookup readlink
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
read wrcache write create remove rename
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
link symlink mkdir rmdir readdir fsstat
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
Server nfs v3:
null getattr setattr lookup access readlink
2 0% 600033 54% 0 0% 100000 9% 400031 36% 0 0%
read write create mkdir symlink mknod
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
remove rmdir rename link readdir readdirplus
0 0% 0 0% 0 0% 0 0% 778 0% 2 0%
fsstat fsinfo pathconf commit
0 0% 1 0% 0 0% 0 0%
>
> Things that can kill NFS:
>
> 1) UDP NFS. Lots of resends especially over routers
I've tried TCP too, it's ever so slighly slower.
> 2) Router/fragmentation. If the router is badly breaking up the UDP
> packets and you are getting them in wrong order.. you will see slow
> data.
> 3) Collisions on the wire. A bad switch or just using hubs will kill
> NFS with lots of resends. [We had a problem that was due to a switch
> in spanning tree mode. Turning it off increased our NFS from one box
> to another by 300%.]
The kernel/nfsstat says no errors and no retransmissions.
> 4) Bad ethernet driver options. A card in half-duplex on a switch with
> duplex will show slow speeds on things that have lots of RPC calls in
> them.
> 5) Bad cable. Least likely..
These machines are in vmware. For the moment, the nfs server and the test mount
machine are on the same blade. The nfs server is directly mounting a LUN on the
SAN.
>
> Seen all of these at any time, and they all would show where an
> /bin/ls -f took no time and /bin/ls -l took forever. The best bets are
> to look at ifconfig and nfsstat to see what the error counts and then
> discount the above in whatever order is best
>
> --
> Stephen J Smoogen.
> CSIRT/Linux System Administrator
>
I've done some more testing, and compared it to another nfs server.
If a client one hop away connects to this other nfs server, an ls -l on the
directory of files takes 15 seconds.
Repeating this, but for the new nfs server, a client one hop away connects, and
an ls -l takes 34 seconds.
If I am on the new nfs server, and I mount the nfs share on the same machine,
ls -l takes 14 seconds.
This compares to about 1 second to do an ls -l on the disk's mountpoint.
I don't know what to try next.
--
Taroon-list mailing list
Taroon-list@(protected)
https://www.redhat.com/mailman/listinfo/taroon-list
|
|
|