Slow NFS connections - Redhat

This is a discussion on Slow NFS connections - Redhat ; While using my NFS shares, I have noticed that there is a severe decrease in speed. I understand that working across a network can be slow, but this seems extreme. For example, when downloading the latest version of Perl directly ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Slow NFS connections

  1. Slow NFS connections

    While using my NFS shares, I have noticed that there is a severe decrease in
    speed. I understand that working across a network can be slow, but this
    seems extreme. For example, when downloading the latest version of Perl
    directly to an NFS share, it will download about 7%, pause for a couple
    seconds, download another 7%, pause and this continues until the download is
    complete. Extracting the file takes about 10 times as long on the NFS share
    as it does locally.

    I am working with servers on a network using 100Mb connections. Does anyone
    know why this may be occuring?

    Thank You,
    Jason Williard



  2. Re: Slow NFS connections

    Make sure that all the NICs are set to the same speed/duplex. I normally
    force all network cards to 100MB/Full Duplex.. Take off the auto
    setting.

    On Thu, 2005-08-11 at 11:23 -0700, Jason Williard wrote:
    > While using my NFS shares, I have noticed that there is a severe decrease in
    > speed. I understand that working across a network can be slow, but this
    > seems extreme. For example, when downloading the latest version of Perl
    > directly to an NFS share, it will download about 7%, pause for a couple
    > seconds, download another 7%, pause and this continues until the download is
    > complete. Extracting the file takes about 10 times as long on the NFS share
    > as it does locally.
    >
    > I am working with servers on a network using 100Mb connections. Does anyone
    > know why this may be occuring?
    >
    > Thank You,
    > Jason Williard
    >
    >



  3. Re: Slow NFS connections

    What release are you using, RedHat ES3 did have NFS problems but I believe
    it was fixed in Update 4? What errors are you seeing if you use nfsstat
    and do you see any errors in the messages file?

    Simon



    On Thu, 11 Aug 2005 11:23:13 -0700, Jason Williard wrote:

    > While using my NFS shares, I have noticed that there is a severe decrease in
    > speed. I understand that working across a network can be slow, but this
    > seems extreme. For example, when downloading the latest version of Perl
    > directly to an NFS share, it will download about 7%, pause for a couple
    > seconds, download another 7%, pause and this continues until the download is
    > complete. Extracting the file takes about 10 times as long on the NFS share
    > as it does locally.
    >
    > I am working with servers on a network using 100Mb connections. Does anyone
    > know why this may be occuring?
    >
    > Thank You,
    > Jason Williard



  4. Re: Slow NFS connections

    In article ,
    Olivier wrote:
    >>

    >Hi had terrible performance on NFS shares because of a duplex mismatch
    >on my network card. The symptom was exactly yours: hi speed, then stall,
    >etc. With an average transfer speed just miserable.
    >Check your interfaces with mii-tool and check also your switches.


    Yes, do everything that people have said, largely because they are
    easy and generically useful checks. But there is a LOT more than can
    cause this, most of which you had better pray you don't see :-(

    With SunOS 4.1 and HP-UX 7/8, there was dire TCP performance one way
    because Sun had taken one approach to tuning (large windows) and HP
    the other (packet aggregation in the kernel). Traditional NFS would
    not see this, but I know that such issues are still extant with some
    combinations of system. And, of course, this does not affect UDP.

    There can be horrible scheduler-related issues. The data paths are
    long, tortuous, and there is no tracing worth a damn. The worst I
    have seen is a transfer taking FIVE (5) seconds from an application
    to the driver (i.e. strace to snoop) on an essentially idle system
    with several times more spare CPUs than runnable threads.

    [ Note that I don't mean JUST the main scheduler here, but include
    such things as implicit scheduling caused by kernel locks, memory
    allocation and so on. These are probably more important for I/O
    data paths than the main process/thread scheduler. ]

    I haven't investigated Linux in enough detail to know the comparable
    problems with it, but I have reason to believe that both of those
    are likely at least in some Linux configurations.


    Regards,
    Nick Maclaren.

+ Reply to Thread