From owner-freebsd-xen@FreeBSD.ORG Fri Jan 20 23:55:40 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EF06106566B for ; Fri, 20 Jan 2012 23:55:40 +0000 (UTC) (envelope-from bsd@xerq.net) Received: from cartman.xerq.net (cartman.xerq.net [67.52.126.46]) by mx1.freebsd.org (Postfix) with ESMTP id 28BDA8FC12 for ; Fri, 20 Jan 2012 23:55:39 +0000 (UTC) Received: from cartman.xerq.net (unknown [127.52.126.46]) by cartman.xerq.net (Postfix) with ESMTP id 71BE94095C; Fri, 20 Jan 2012 15:55:39 -0800 (PST) Received: from cartman.xerq.net ([127.52.126.46]) by cartman.xerq.net (cartman.xerq.net [127.52.126.46]) (amavisd-new, port 10024) with ESMTP id r9M55Jf7xh3G; Fri, 20 Jan 2012 15:55:34 -0800 (PST) Received: from www1.xerq.net (localhost [127.52.126.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by cartman.xerq.net (Postfix) with ESMTPSA id 5FE8240939; Fri, 20 Jan 2012 15:55:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 20 Jan 2012 15:55:33 -0800 From: Matt Connor To: Michael MacLeod In-Reply-To: References: <7840786B-5C23-4C6D-AEE5-3DC23E96FC82@kfu.com> <4F18A4F2.7040205@delphij.net> <65d33d61a2d7c4ccc167658407f5b189@www1.xerq.net> Message-ID: X-Sender: bsd@xerq.net User-Agent: XERQ Webmail/0.7.1 Cc: freebsd-xen@freebsd.org, d@delphij.net Subject: Re: 9.0-RELEASE success X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:55:40 -0000 On 2012-01-19 18:18, Michael MacLeod wrote: > On Thu, Jan 19, 2012 at 9:06 PM, Matt Connor > wrote: > >> On 2012-01-19 15 [3]:19, Xin Li wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 01/19/12 13:22, Matt Connor wrote: >>> >>>> On 19.01.2012 13:15, Nick Sayer wrote: >>>> >>>>> I have a VPS at rootbsd.net [1], and have been running >>>>> 8.2-RELEASE >>>>> with a XENHVM kernel with a patch to fix the do something >>>>> smart >>>>> panic in if_xn. I fetched the 9.0-RELEASE source tree and >>>>> built a >>>>> kernel to try and it worked without any muss or fuss. I did >>>>> the >>>>> rest of the upgrade and its working just fine, so far as I >>>>> can >>>>> tell. >>>>> >>>>> And there was much >>>>> rejoicing._______________________________________________ >>>> >>>> Same here at ssdnodes.com [2] - we pulled the new source tree, >>>> rebuilt >>>> with our modified XENHVM and havent had any issues so far. >>>> >>>> We had many tweaks in /etc/sysctl.conf to improve throughput >>>> for >>>> the 8.2-RELEASE, the 9.0-RELEASE systems still remained snappy >>>> after the tweaks were removed. >>> >>> What kinds of tweaks are needed?  (i.e. should we make them the >>> defaults?) >> >> The tweaks were only "needed" because we were trying to achieve a >> specific network throughput in our particular workload (read: >> turning the knob all the way until it broke off). These values are >> no longer in production on version 9.0-RELEASE, I highly recommend >> these never become default. >> >> For your amusement, Ive included the values below: >> >> <<<...SNIP...>>> > > Any of these recommended for those of us who arent rushing to leave > 8.2 yet? > > Links: > ------ > [1] http://rootbsd.net > [2] http://ssdnodes.com It honestly depends on what you're trying to accomplish, I can't give any blanket advice that will cover all the various workloads. Ours in particular was serving a combination of many small image files and a few large files that were being constantly hit between 150-300Mbps. After a month or two of benchmarking, we found these values to help considerably. If your workload is similar (or you're feeling particularly sadistic today), I would suggest doing rigorous benchmarks on your current system, then changing the sysctl values one-by-one and making note of the changes in performance. Unfortunately you cannot do the same with the /boot/loader.conf values (these actually require a reboot).