[mythtv-users] diskless frontend nfs throughput

[Dan Littlejohn]

On Fri, Aug 7, 2009 at 7:51 AM, Dan Littlejohn <dan.littlejohn at gmail.com>wrote:

>
>
> 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
>>
>
Dang, I left the "k" off my read test.  Looks like I am good to go now.
Thanks for the help.

Dan

 one pxelinux.cfg # time dd if=/store/video/test of=/dev/null bs=16k
154614+1 records in
154614+1 records out
2533208064 bytes (2.5 GB) copied, 56.4591 s, 44.9 MB/s

real    0m56.509s
user    0m0.163s
sys     0m26.802s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090807/683349df/attachment.htm>