[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    Re: [Netatalk-admins] Trying to understand the means of tuning
From:       didier <dgautheron () magic ! fr>
Date:       2009-10-26 13:28:27
Message-ID: 1256563707.20396.58.camel () server
[Download RAW message or body]

Hi,
Le dimanche 25 octobre 2009 à 20:33 +0100, Stephan Budach a écrit :
> schrieb Frank Lahm, Am 25.10.09 19:13:
> > 2009/10/25 Stephan Budach<stephan.budach@jvm.de>:
> > > Hi all,
> > > 
> > > I have spend the last couple of hours to try to tune my netatalk installation \
> > > to gain some more performance. I am running netatalk 2.1dev on a CentOS 5.4 \
> > > system. 
> > > I have netatalk compiled against BDB-4.7 and I played a bit with the db_param \
> > > and even DB_CONFIG, but I never could notice any difference in performance. 
> > > My particular areas of interest are:
> > > 
> > > - deleting of multiple files from eyeTV
> > > - extreme slow startup of Aperture, where it's library is located on a netatalk \
> > > volume 
> > > Is there any rundown for performance-tuning for netatalk?
Not really. increasing flush_frequency in db_param may help.
> > 
> > In the end there won't be much you could tune anyway. You might
> > however might like to compare your setup with another AFP server on
> > comparable hardware and netlink. If that shows some significant
> > differerence, it'd be interested in more data.
> 
> ha ha - I don't think that I have a comparable hardware at hand. I am running \
> netatalk on a 1.5 GHz Celeron M CPU on a Thecus N5200Pro NAS, where I installed \
> CentOS onto. 
> This box has 1 GB of RAM and a 5-disk MD RAID5 on a GBit link. I have moved the \
> cnid DBs to a ramdisk, to eliminate all disk accesses when dealing with afpd, but \
> depending on the use case, there're little to no differences in performance. I \
> think that dealing with lots of files breaks the performance, while a single or few \
> transactions seem to run fairly well. 
> Leaving the Finder's own caching aside, du -hs on my Aperture Library, that \
> consists of 42k files/5.5 GB (without the actual photos) takes approx 38s to \
> complete, while it only takes about 1s on the local file system. 

What's in your .volinfo, afpd.conf and AppleVolumes.default?

With current HEAD we're caching cnid id in resource forks but I'm not
sure we are setting them in old resources.
You could try with a new volume.
 
IF you run top on the server is the client able to load the server to
100%? 

'du' is a hard test, a good POSIX --> AFP should be able to get a
slowdown of around 5 vs a local run because AFP can return metadata in
directories enumeration and it can stream requests.
But OSX clients don't use it, they request the directory listing and for
each file request its info. 
Of course these thousands synchronous requests/replies kill
performance. 

Didier



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Netatalk-admins mailing list
Netatalk-admins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-admins


[prev in list] [next in list] [prev in thread] [next in thread]