From owner-freebsd-performance@freebsd.org Fri Jun 3 18:27:24 2016 Return-Path: Delivered-To: freebsd-performance@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 066B7B68EAE for ; Fri, 3 Jun 2016 18:27:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D89121707 for ; Fri, 3 Jun 2016 18:27:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D150CB68EA8; Fri, 3 Jun 2016 18:27:23 +0000 (UTC) Delivered-To: performance@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFCD3B68EA6; Fri, 3 Jun 2016 18:27:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 982451702; Fri, 3 Jun 2016 18:27:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x230.google.com with SMTP id p194so83054702iod.1; Fri, 03 Jun 2016 11:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KYSrGvKkDPpfkFFqk0QJVYR360zHdOdndByM16Z1gQc=; b=gYggnWB0Cd8noDUdzPNp1ckdilRl0/FPwbqnT26rDflwYzSCwqm1JcDx9dkzNlUmIg /V+di/CnlTf8vVLpVbQAp4OFVArWUZwaqLbn6JV69L7COoFOI1y9/ewmPE/H5YWUmgWM q4Y21zF9H9yhOBA3T+R/g0Pp0yXj202V4gDTx58+lwNPkRtSrQP5d/KZVNbDBgSM8es4 0KyPeguj9tOUty8H6vqhd8Y24a5RK1/GYtipz6c5uTYh5PdfucbHx3wR+zJ/J+kQ3eCo JE+6lLo6xPy/HEd8x38OusxC30i2HSnmhJTaXrDwWxXcrcNMh5xioNIAT0Hw09x5b7p9 mHUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KYSrGvKkDPpfkFFqk0QJVYR360zHdOdndByM16Z1gQc=; b=LD+49TE2rWlO4Ck0WrOdsYdYSHL9BEPmIRP24okgb8iZR7ulqq1E+tv8svOhWdssRY gwk4IWYyoGzyYkM+D2Pwe1hC6NvllXBd+xSHuhAPVBX997yiq49WPn6rULdePoPgaRXQ d1aVrkuBGsLHuTUZZJjpjC1tg8LGTPFjJo9sRsCEzBP3GVtvGNK488EvHf0ixseZBpZl orKbicdZ91GLsEi/ZDDCHW2hm1oKsqc+U3kX5UiFe2yPIfKB6K3Yxa47nx/i8Ydh0/TA YkHBEd35pL2DD5HguDWdRfyXssCMsstqmQUYqzh/CQh3fBYVHrtqnTvoX5s+bVghghtp IPyQ== X-Gm-Message-State: ALyK8tL+kRhZjbYNGx/7RX1b5Cw6papnfiQKYiB+4SuNFa40/F65TywbDIYfgwkGEueAn58YPBBdFJiNvoR4mQ== X-Received: by 10.36.81.79 with SMTP id s76mr1333740ita.71.1464978442929; Fri, 03 Jun 2016 11:27:22 -0700 (PDT) MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Fri, 3 Jun 2016 11:27:21 -0700 (PDT) In-Reply-To: <20160603175546.GZ38613@kib.kiev.ua> References: <20140627125613.GT93733@kib.kiev.ua> <201408121409.40653.jhb@freebsd.org> <201408141147.45698.jhb@freebsd.org> <53ECFDC8.1070200@rice.edu> <20160603172633.GY38613@kib.kiev.ua> <20160603175546.GZ38613@kib.kiev.ua> From: Adrian Chadd Date: Fri, 3 Jun 2016 11:27:21 -0700 X-Google-Sender-Auth: gR6yv1SFYVzC9Sqq7mfFCO6qbuI Message-ID: Subject: Re: PostgreSQL performance on FreeBSD To: Konstantin Belousov Cc: Alan Somers , Alan Cox , John Baldwin , Alan Cox , freebsd-current , performance@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 18:27:24 -0000 On 3 June 2016 at 10:55, Konstantin Belousov wrote: > On Fri, Jun 03, 2016 at 11:29:13AM -0600, Alan Somers wrote: >> On Fri, Jun 3, 2016 at 11:26 AM, Konstantin Belousov >> wrote: >> > On Fri, Jun 03, 2016 at 09:29:16AM -0600, Alan Somers wrote: >> >> I notice that, with the exception of the VM_PHYSSEG_MAX change, these >> >> patches never made it into head or ports. Are they unsuitable for low >> >> core-count machines, or is there some other reason not to commit them? >> >> If not, what would it take to get these into 11.0 or 11.1 ? >> > >> > The fast page fault handler was redesigned and committed in r269728 >> > and r270011 (with several follow-ups). >> > Instead of lock-less buffer queues iterators, Jeff changed buffer allocator >> > to use uma, see r289279. Other improvement to the buffer cache was >> > committed as r267255. >> > >> > What was not committed is the aggressive pre-population of the phys objects >> > mem queue, and a knob to further split NUMA domains into smaller domains. >> > The later change is rotten. >> > >> > In fact, I think that with that load, what you would see right now on >> > HEAD, is the contention on vm_page_queue_free_mtx. There are plans to >> > handle it. >> >> Thanks for the update. Is it still recommended to enable the >> multithreaded pagedaemon? > > Single-threaded pagedaemon cannot maintain the good system state even > on non-NUMA systems, if machine has large memory. This was the motivation > for the NUMA domain split patch. So yes, to get better performance you > should enable VM_NUMA_ALLOC option. > > Unfortunately, there were some code changes of quite low quality which > resulted in the NUMA-enabled system to randomly fail with NULL pointer > deref in the vm page alloc path. Supposedly that was fixed, but you > should try that yourself. One result of the mentioned changes was that > nobody used/tested NUMA-enabled systems under any significant load, for > quite long time. The iterator bug was fixed, so it still behaves like it used to if NUMA is enabled circa what, freebsd-9? If you'd like that older behavior, you can totally flip back to the global policy being round-robin only, and it's then a glorified, configurable-at-runtime no-op. The difference now is that you can tickle imbalances if you have too many processes that need pages from a specific domain instead of round robin, because the underlying tracking mechanisms still assume a single global pool and global method of cleaning things. That and the other NUMA stuff is something to address in -12. -adrian