Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b6Pm0-0002aA-7J for pgsql-hackers@arkaria.postgresql.org; Fri, 27 May 2016 21:58:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1b6Plz-0001tD-L9 for pgsql-hackers@arkaria.postgresql.org; Fri, 27 May 2016 21:58:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b6Pke-0000KU-0A for pgsql-hackers@postgresql.org; Fri, 27 May 2016 21:57:04 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1b6Pka-0007hB-TL for pgsql-hackers@postgresql.org; Fri, 27 May 2016 21:57:03 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D0E7F20431; Fri, 27 May 2016 17:56:58 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Fri, 27 May 2016 17:56:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=k3BGIIYgpWO3PGhYR1gNmIiSurw=; b=lIful suZjJwY4544HCt6AxBSSFCR/5a+QdlBgqPx4RfOC+NBYFDHvC8IQVv4AFRHYNlvT eBSClxK9q3Xysu4W1FDbMepn/XgiiOYQgSSlRwpDmzfszSYpsRugyCzoHpx37qjx Rz+EcqXfCDAj4gS08WbQ5aJ8FMcVtp0KVVC5J4= X-Sasl-enc: 8HaEWE+9xCT8DhpbgocsH/kozCKaOfpuAFAbWt4ZCM/W 1464386218 Received: from intern.anarazel.de (somacentral.static.monkeybrains.net [162.217.75.74]) by mail.messagingengine.com (Postfix) with ESMTPA id 8357ECC070; Fri, 27 May 2016 17:56:58 -0400 (EDT) Date: Fri, 27 May 2016 14:56:57 -0700 From: Andres Freund To: Vladimir Borodin Cc: PostgreSQL-development , pgbouncer-general@lists.pgfoundry.org Subject: Re: 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6 Message-ID: <20160527215657.lsjevmtm2qx3mxcd@alap3.anarazel.de> References: <26239E39-A838-4611-B7BA-0E96D2DF3253@simply.name> <910CBF45-90EB-44D6-9640-22638C2F26F7@simply.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <910CBF45-90EB-44D6-9640-22638C2F26F7@simply.name> X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Hi, On 2016-05-27 19:57:34 +0300, Vladimir Borodin wrote: > -performance > > Here is how the results look like for 9.4, 9.5 and 9.6. All are built from latest commits on yesterday in > > * REL9_4_STABLE (a0cc89a28141595d888d8aba43163d58a1578bfb), > > * REL9_5_STABLE (e504d915bbf352ecfc4ed335af934e799bf01053), > > * master (6ee7fb8244560b7a3f224784b8ad2351107fa55d). > > > > All of them are build on the host where testing is done (with stock gcc versions). Sysctls, pgbouncer config and everything we found are the same, postgres configs are default, PGDATA is in tmpfs. All numbers are reproducible, they are stable between runs. > > > > Shortly: > > > > OS PostgreSQL version TPS Avg. latency > > RHEL 6 9.4 44898 1.425 ms > > RHEL 6 9.5 26199 2.443 ms > > RHEL 6 9.5 43027 1.487 ms > > Ubuntu 14.04 9.4 67458 0.949 ms > > Ubuntu 14.04 9.5 64065 0.999 ms > > Ubuntu 14.04 9.6 64350 0.995 ms > > The results above are not really fair, pgbouncer.ini was a bit different on Ubuntu host (application_name_add_host was disabled). Here are the right results with exactly the same configuration: > > OS PostgreSQL version TPS Avg. latency > RHEL 6 9.4 44898 1.425 ms > RHEL 6 9.5 26199 2.443 ms > RHEL 6 9.5 43027 1.487 ms > Ubuntu 14.04 9.4 45971 1.392 ms > Ubuntu 14.04 9.5 40282 1.589 ms > Ubuntu 14.04 9.6 45410 1.409 ms Hm. I'm a bit confused. You show one result for 9.5 with bad and one with good performance. I suspect the second one is supposed to be a 9.6? Am I understanding correctly that the performance near entirely recovered with 9.6? If so, I suspect we might be dealing with a memory alignment issue. Do the 9.5 results change if you increase max_connections by one or two (without changing anything else)? What's the actual hardware? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers