From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 14:51:53 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66A77B8 for ; Mon, 8 Jul 2013 14:51:53 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DDF1516B3 for ; Mon, 8 Jul 2013 14:51:52 +0000 (UTC) Received: (qmail 62760 invoked from network); 8 Jul 2013 15:42:58 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 8 Jul 2013 15:42:58 -0000 Message-ID: <51DAD207.3090008@freebsd.org> Date: Mon, 08 Jul 2013 16:51:51 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Outback Dingo Subject: Re: status of autotuning freebsd for 9.2 References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org, Alfred Perlstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:51:53 -0000 On 08.07.2013 16:41, Outback Dingo wrote: > > > > On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann > 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 > > > 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