[mythtv-users] diskless frontend nfs throughput

Dan Littlejohn dan.littlejohn at gmail.com
Fri Aug 7 12:51:13 UTC 2009


On Fri, Aug 7, 2009 at 3:28 AM, belcampo <belcampo at zonnet.nl> wrote:

> Jim Stichnoth wrote:
>
>> On Thu, Aug 6, 2009 at 11:05 AM, Dan Littlejohn<dan.littlejohn at gmail.com>
>> wrote:
>>
>>> I have a gentoo diskless frontend that mounts using nfs and it seems like
>>> the throughput of nfs is slow.  iperf show the network able to push 770
>>> Mb/s
>>> and hdparm shows the sata disk on the server at 90 Mb/s, but doing a dd
>>> across the network only shows up as 10 Mb/s  (is about 40 Mb/s when the
>>> same
>>> test is done on the server to a third machine).
>>>
>>> Odd thing is that the pxeboot mounts nfsver2.  Not sure if this is a
>>> problem
>>> or not, but other mounts after boot mount as nfsver3.  Really seems like
>>> it
>>> is a config problem with nfs somewhere, but I have not found anything
>>> that
>>> makes a difference.  Doing rsize=8k,wsize=8k, noatime, async.  Anyone
>>> have
>>> any tips to look for or is this 10 Mb/s really the throughput I should
>>> expect for a diskless frontend?
>>>
>> Remove those rsize=8k,wsize=8k, the default of current kernels is
> rsize=1048576,wsize=1048576
> Client/server negotiate max possible blocksize.
> If server is defaulting to a 'not optimum' block-size you can override that
> with
> echo 1048576 > /proc/fs/nfsd/max_block_size
> in one of your initscripts
>
>
>> My diskless MythDora 10.21 frontend uses NFS.  I timed a copy of a 4GB
>> file from the NFS server into /dev/null and got about 41 MB/s (or 330
>> Mb/s).  This is over a gigabit wired network.  The only special mount
>> option to speak of is "nolock" presumably because the lockd is not
>> part of the initrd image.
>>
>> Jim
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv<http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users>
>
> Well, I got a bit farther.  Letting the block size auto negociated made the
> write faster (Thanks Belcampo), but the read is still slow.  Is the
> /etc/init.d/nfsd script where you set the proc max_block_size echo?  I am
> running pxelinux so I believe I have to hard set the rsize and wsize in the
> pxelinux.cfg boot file, but it seems to make no difference to the read speed
> for different values I tried.
>
> Here is a bit more info below with letting everything auto negociate with
> defaults including pxelinux when the root file system is mounted.  Any other
> suggestions to try to find the read bottleneck?
>
> Dan
>
>  one ~ # nfsstat -m
> / from /dev/root
>  Flags:
> rw,vers=3,rsize=4096,wsize=4096,namlen=255,hard,nointr,nolock,proto=tcp,
> timeo=600,retrans=2,sec=sys,addr=192.168.0.5
>
> /store/tv from 192.168.99.99:/store/tv
>  Flags:
> rw,noatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,nointr,noloc
>
> k,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.99.99,mountvers=3,mountp
> roto=tcp,addr=192.168.99.99
>
> one ~ # time dd if=/dev/zero of=/store/tv/test bs=16k count=10000
> 10000+0 records in
> 10000+0 records out
> 163840000 bytes (164 MB) copied, 2.79913 s, 58.5 MB/s
>
> real    0m3.048s
> user    0m0.033s
> sys     0m1.983s
> one ~ # time dd if=/store/tv/test of=/dev/null bs=16
> 10240000+0 records in
> 10240000+0 records out
> 163840000 bytes (164 MB) copied, 15.548 s, 10.5 MB/s
>
> real    0m15.558s
> user    0m3.153s
> sys     0m12.313s
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090807/040d546f/attachment.htm>


More information about the mythtv-users mailing list