From owner-freebsd-stable@FreeBSD.ORG Fri Aug 15 16:37:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45622534 for ; Fri, 15 Aug 2014 16:37:59 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1021A27C8 for ; Fri, 15 Aug 2014 16:37:59 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id hn18so2422700igb.3 for ; Fri, 15 Aug 2014 09:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3lQuN9HzcCi+OeGMrUW7d/VmKke6c0+qaHTrtqtVuNo=; b=gGUIz/twaQrRn25ewzkygguYLa7FHPuc1i+FvielWwmsefwC9GRntBOvLpftP5NjJQ sqrUePPOlXh/6n11G+933gRoBnnTGeg+ZzTtWoREwLD3kAjr/uKz5gCNTn5Cc3xWGHoW xk2X7lm+6ztMjD8LHkpzPS2ctVCxAXdJa1P+Z4Bvqb94+c1ImW4ytuBY9eerrXzfgyJQ 7pG4d+YHEKf89S33MYvWR+M/t2kT0RWhNuky9z6G6DqUFXsEGwxC+eXLfGVqjGHD8o3i 5ACt8MkBGPaxepDbuPW9zflUOzuJuM53s28LcwQnPszRG747jXxg65oOQp7Cd9Ax7cZU u+BQ== MIME-Version: 1.0 X-Received: by 10.50.4.9 with SMTP id g9mr25600081igg.42.1408120678431; Fri, 15 Aug 2014 09:37:58 -0700 (PDT) Received: by 10.43.17.196 with HTTP; Fri, 15 Aug 2014 09:37:58 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: References: <4D557EC7CC2A544AA7C1A3B9CBA2B36726098846B4@exchange03.epbs.com> <20140813152522.GI9400@home.opsec.eu> <4D557EC7CC2A544AA7C1A3B9CBA2B36726098847AF@exchange03.epbs.com> Date: Fri, 15 Aug 2014 11:37:58 -0500 Message-ID: Subject: Re: vmdaemon CPU usage and poor performance in 10.0-RELEASE From: Alan Cox To: Ronald Klop Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-stable@freebsd.org" , Kurt Jaeger , "Polyack, Steve" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:37:59 -0000 On Fri, Aug 15, 2014 at 3:43 AM, Ronald Klop wrote: > On Wed, 13 Aug 2014 17:42:37 +0200, Polyack, Steve < > Steve.Polyack@intermedix.com> wrote: > > >> -----Original Message----- >>> From: Kurt Jaeger [mailto:lists@opsec.eu] >>> Sent: Wednesday, August 13, 2014 11:25 AM >>> >>> Hi! >>> >>> > We have a handful of database servers running FreeBSD 10.0-RELEASE >>> > and PostgreSQL 9.3.4. The servers have 128GB or 256GB of RAM. >>> >>> Are you aware of the recent work on that topic ? >>> >>> https://www.freebsd.org/news/status/report-2014-04-2014- >>> 06.html#PostgreSQL-Performance-Improvements >>> >>> Maybe kib@ knows more about this ? >>> >>> >> I've recently read over this and some other posts, but they all seem to >> center around poor postgres performance. In our case at least, some light >> to medium usage of postgres generally makes the entire system unusable. >> >> The patches & documents linked there also all seem to be for -CURRENT, >> which we aren't running. We're not too keen on the idea of using CURRENT >> in production, either. We're planning on testing 10-STABLE, but I was just >> hoping to gain some insight into what the problem may be and whether recent >> commits to vmdaemon code in the -STABLE tree may have a positive effect on >> what we've seen. >> >> Steve >> > > It looks like a fix mentioned in part 2.1 in the pdf ( > https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf, from the status report) > was only just committed to 11-CURRENT. > http://svnweb.freebsd.org/changeset/base/270011 > > I guess it is advisable to stay on pgsql 9.2.x until these improvements > are MFC'ed to 10-STABLE. > > The issues discussed in Kostik's report have nothing to do with the page daemon or the problem that started this thread. 10.0 had a regression in page daemon operation that I fixed in r265945. Alan