FAI performance

[Michael Senizaiz]

Sounds to me like you have a network issue, NFS timeouts shouldn't occur
unless there are lost packets -- if the disk is stuck in I/O wait the NFS
process can still respond.  Check your interfaces and switches for
dropped/errored packets.  You should be able to host hundreds of clients
off a 1G, it would just be slower.  The fai NFS config space hosts very
little data, most of the action is spent transferring the .deb's via HTTP,
and not NFS.  Each step only requires reading in a couple small files
(class definitions, .var files, scripts) and it would take an obscene
amount of hosts accessing these small files to use up a 10g link.

If your config space is over a meg in total, I'd be surprised.   This is
not the issue.

I have some large tarballs in mine (a few gig) and it moves along smoothly
with 100 nodes going at once.



On Mon, Sep 24, 2012 at 9:06 AM, Michał Dwużnik <michal.dwuznik at gmail.com>wrote:

> Well,
>
> in my not quite so 10GbE  env I experience NFS timeouts when doing 16
> machines at a time.
> Moving the fai configspace onto ramdisk helps for the rooms equipped with
> 1Gbps,
> yields _lots_ of 'NFS not responding, still trying' for one forgotten room
> which has still has 100Mbit....
>
> Hence my original question  (which seems to be in line with Nicolas
> Courtel experience)
>
> Regards
> Michal
>
>
>
>
>
> On Mon, Sep 24, 2012 at 2:03 PM, Thomas Lange <
> lange at informatik.uni-koeln.de> wrote:
>
>> >>>>> On Fri, 21 Sep 2012 22:06:27 +0200, Michał Dwużnik <
>> michal.dwuznik at gmail.com> said:
>>
>>     > by the way - what are the default options of mounting the NFS by
>> FAI when installing?
>>     > (rsize in particular, atime?)
>> Using a squeeze install server and FAI 3.4.8 I get these NFS
>> parameters from cat /proc/mounts
>>
>> 1.2.3.149:/srv/fai/nfsroot-squeeze64 /live/image nfs
>> ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,port=65535,timeo=7,retrans=3,sec=sys,mountport=65535,addr=1.2.3.149
>> 0 0
>>
>> IMO there's no need to set the rsize parameter.
>>
>> --
>> regards Thomas
>>
>
>
>
> --
> Michal Dwuznik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20120924/344cc761/attachment.html>