From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 23 16:44:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1D8106566C for ; Thu, 23 Feb 2012 16:44:32 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id BEB4A8FC0C for ; Thu, 23 Feb 2012 16:44:31 +0000 (UTC) Received: by obcwo16 with SMTP id wo16so2182939obc.13 for ; Thu, 23 Feb 2012 08:44:31 -0800 (PST) Received-SPF: pass (google.com: domain of yanegomi@gmail.com designates 10.182.144.68 as permitted sender) client-ip=10.182.144.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of yanegomi@gmail.com designates 10.182.144.68 as permitted sender) smtp.mail=yanegomi@gmail.com; dkim=pass header.i=yanegomi@gmail.com Received: from mr.google.com ([10.182.144.68]) by 10.182.144.68 with SMTP id sk4mr867504obb.4.1330015471245 (num_hops = 1); Thu, 23 Feb 2012 08:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qi4juOhwfEcyo13zpePXamVkEqTSObFPWFFZCSWYPNA=; b=a0zPmU/pLLHyQkL8lY/xYVbRL5zlisQikegFW3xPrgiGOp/WcCPcZr2os23RewEUvc 3hQO9Ip6SW0gGKRMhhGYj0EyI93KVnyK1NUYAibJeo3bbEa4E7IbYFv0Kus62Ej91JWu nivcFCu8auBFgqLP10zsGM9AXMF3qwJ3zkjio= MIME-Version: 1.0 Received: by 10.182.144.68 with SMTP id sk4mr746051obb.4.1330015471168; Thu, 23 Feb 2012 08:44:31 -0800 (PST) Received: by 10.182.80.200 with HTTP; Thu, 23 Feb 2012 08:44:31 -0800 (PST) In-Reply-To: <4F46500D.3070609@my.gd> References: <4F45AB76.5050201@FreeBSD.org> <201202230822.16304.jhb@freebsd.org> <4F46500D.3070609@my.gd> Date: Thu, 23 Feb 2012 08:44:31 -0800 Message-ID: From: Garrett Cooper To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: PostgreSQL benchmarks (now with Linux numbers) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:44:32 -0000 On Thu, Feb 23, 2012 at 6:41 AM, Damien Fleuriot wrote: > > > On 2/23/12 2:22 PM, John Baldwin wrote: >> On Wednesday, February 22, 2012 9:59:02 pm Doug Barton wrote: >>> On 02/22/2012 01:42, Ivan Voras wrote: >>>> The Dragonfly team has recently liberated their VM from the giant lock= and there are some interesting benchmarks comparing it to FreeBSD 9 and a >> derivative of RedHat Enterprise Linux: >>>> >>>> http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00008.html >>>> >>>> Other developments are described in their release notes: http://www.dr= agonflybsd.org/release30/ >>> >>> The 4.5 times improvement by enabling kern.ipc.shm_use_phys is pretty >>> notable, what prevents us from enabling that by default? >> >> It makes all your SYSV SHMs wired. =A0That's fine if you are running a d= edicated >> server using SYSV SHMs where you want that process to use all the RAM in= the >> machine (e.g. a pgqsl server). =A0It's not so great for a general purpos= e load >> where you would like an otherwise-idle process using SYSV SHMs to have t= he SHMs >> paged out to swap if other processes on the machine need memory and the = box is >> under memory pressure. >> > > John, any chance we can get that in layman's terms ? > > I'm totally no coder, but I'd really like if we could do this at my work > place to increase our firewalls' performances. (simplifying things... If postgres is the only man in town, then having SYSV SHM (system 5 shared memory) wired down in the kernel would be fine. However, if postgres's not the only man in town, postgres will starve other applications (say Firefox) so they can't get the resources they need to work. A good real life example -- similar to the above -- of memory starvation situations is ZFS v28 on boxes where vfs.zfs.arc_max isn't tuned and the system RAM is overcommitted, such that ZFS will starve userland of all available RAM in the right scenarios. Granted, this scenario uses KVM (kernel virtual memory), not SYSV SHM (this is a subset of KVM), but the general concept (limited resources -> consumer doesn't give up resources -> other waiters starve) is very much the same. HTH, -Garrett