Following up on my previous posts, I have now successfully increased the size
of the DNLC from 450,000 (default) to 10,000,000, by following the /etc/system
override method explained at
<http://dtrace.org/blogs/wesolows/2013/12/28/anonymous-tracing-on-smartos/>
Unfortunately, this has not solved the problem. I am still seeing very poor
performance from the OS X 10.9 Finder when viewering directories served from
the SmartOS server using netatalk 3.1.2. Subjectively, performance is somewhat
better, but opening folders still takes 10-20 seconds when it should be almost
instantaneous.
A new Flame Graph shows that now the kernel is still spending most of its time
in getcwd(), though now that is divided to a large amount between mutex_enter()
and mutex_leave(), with the lesser part actually spent in
dnlc_reverse_lookup(). The new Flame Graph is here:
<http://fere.be/p/netatalk-flamegraph-2.svg>
and a new Dtrace analysis from afp.d is here:
<https://gist.github.com/ferebee/0f8169cd0ea19b656c51>
Netatalk developer Ralph Böhme suggests that the observed slow performance of
getcwd might be specific to Illumos, and this comment from the netatalk mailing
list would seem to point in a similar direction:
<http://sourceforge.net/p/netatalk/mailman/message/24468503/>
It references a comment from the Samba source code
<https://ftp.samba.org/pub/unpacked/samba_3_next/source3/smbd/vfs.c> which says:
/*
* We don't have the information to hand so rely on traditional
* methods. The very slow getcwd, which spawns a process on some
* systems, or the not quite so bad getwd.
*/
This raises the question, what is the expected behavior of getcwd() on
SmartOS/Illumos/Solaris? If it is in fact very slow, and netatalk relies
heavily on it, perhaps Illumos is not a good choice for a netatalk server?
Or is there a way to optimize this after all within SmartOS?
Thanks all,
Chris
Am 02.08.2014 um 17:57 schrieb Richard Elling via smartos-discuss
<[email protected]>:
>> enters 1858063
>> hits 2546253549
>> misses 2531297654
>> negative_cache_hits 22475516
>> pick_free 0
>> pick_heuristic 995275
>> pick_last 3997
>
> pick_heuristic and pick_last are the import indicators that your DLNC could
> be
> too small. Ideally, these are 0.
>
> Somewhere around here I've got a dnlcstat... there is one in the dtrace
> toolkit,
> but you can also do one using just kstats instead.
> -- richard
-------------------------------------------
smartos-discuss
Archives: https://www.listbox.com/member/archive/184463/=now
RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00
Modify Your Subscription:
https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb
Powered by Listbox: http://www.listbox.com
