status of autotuning freebsd for 9.2

[Andre Oppermann]

On 08.07.2013 16:41, Outback Dingo wrote:
>
>
>
> On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann <andre at freebsd.org <mailto:andre at freebsd.org>> wrote:
>
>     On 07.07.2013 20:24, Alfred Perlstein wrote:
>
>         On 7/7/13 1:34 AM, Andre Oppermann wrote:
>
>             Can you help me with with testing?
>
>         Yes.  Please give me your proposed changes and I'll stand up a machine and give feedback.
>
>
>     http://people.freebsd.org/~__andre/mfc-autotuning-20130708.__diff
>     <http://people.freebsd.org/%7Eandre/mfc-autotuning-20130708.diff>
>
>     This is functional bundle MFC of these original commits:
>
>     MFC r242029 (alfred):
>
>       Allow autotune maxusers > 384 on 64 bit machines.
>
>     MFC r242847 (alfred):
>
>       Allow maxusers to scale on machines with large address space.
>
>     MFC r243631 (andre):
>
>       Base the mbuf related limits on the available physical memory or
>       kernel memory, whichever is lower.  The overall mbuf related memory
>       limit must be set so that mbufs (and clusters of various sizes)
>       can't exhaust physical RAM or KVM.
>
>       At the same time divorce maxfiles from maxusers and set maxfiles to
>       physpages / 8 with a floor based on maxusers.  This way busy servers
>       can make use of the significantly increased mbuf limits with a much
>       larger number of open sockets.
>
>     MFC r243639 (andre):
>
>       Complete r243631 by applying the remainder of kern_mbuf.c that got
>       lost while merging into the commit tree.
>
>     MFC r243668 (andre):
>
>       Using a long is the wrong type to represent the realmem and maxmbufmem
>       variable as they may overflow on i386/PAE and i386 with > 2GB RAM.
>
>     MFC r243995, r243996, r243997 (pjd):
>
>       Style cleanups, Make use of the fact that uma_zone_set_max(9) already
>       returns actual limit set.
>
>     MFC r244080 (andre):
>
>       Prevent long type overflow of realmem calculation on ILP32 by forcing
>       calculation to be in quad_t space.  Fix style issue with second parameter
>       to qmin().
>
>     MFC r245469 (alfred):
>
>       Do not autotune ncallout to be greater than 18508.
>
>     MFC r245575 (andre):
>
>       Move the mbuf memory limit calculations from init_param2() to
>       tunable_mbinit() where it is next to where it is used later.
>
>     MFC r246207 (andre):
>
>       Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define.
>
>     MFC r249843 (andre):
>
>       Base the calculation of maxmbufmem in part on kmem_map size
>       instead of kernel_map size to prevent kernel memory exhaustion
>       by mbufs and a subsequent panic on physical page allocation
>       failure.
>
>
>
> would it be safe to throw a couple of high end storage systems into this testing pool ??
> each has 128G Memory, and dual quad core procs, with 10GB Intel interfaces all they
> are design to do it samba and nfs and ive been fighting performance with samba and
> nfs on these systems, Id be curious if autotuning might help, to be honest, theres so
> much to tweak for samba, nfs, zfs alone in different formats, im surprised anyone has
> it running efficiently.

I don't know enough about the limits of Samba setups.  Testing this
MFC may or may not significantly improve the performance, though at
least we'll know that it doesn't hurt.

-- 
Andre