Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1go7nw-0003EW-GU
	for pgsql-performance@arkaria.postgresql.org; Mon, 28 Jan 2019 14:22:28 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1go7nt-0006Q6-4f
	for pgsql-performance@arkaria.postgresql.org; Mon, 28 Jan 2019 14:22:25 +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_SHA1:256)
	(Exim 4.89)
	(envelope-from <nicolas.charles@normation.com>)
	id 1go7ns-0006Pz-TD
	for pgsql-performance@lists.postgresql.org; Mon, 28 Jan 2019 14:22:24 +0000
Received: from nrm-vir-mail-01.normation.com ([212.129.19.75])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <nicolas.charles@normation.com>)
	id 1go7nq-00055W-9K
	for pgsql-performance@lists.postgresql.org; Mon, 28 Jan 2019 14:22:24 +0000
Received: from [192.168.90.10] (republique-1.normation.com [78.249.200.184])
	by nrm-vir-mail-01.normation.com (Postfix) with ESMTPSA id CA9E8223926;
	Mon, 28 Jan 2019 15:22:19 +0100 (CET)
Subject: Re: Benchmarking: How to identify bottleneck (limiting factor) and
 achieve "linear scalability"?
To: Saurabh Nanda <saurabhnanda@gmail.com>, Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
References: 
 <CAPz=2oGdmvirLNX5kys+uiY7LKzCP4sTiXXob39qq6eDkEuk2Q@mail.gmail.com>
 <CAMkU=1yNvhDow9QvKeG5nzv2fDG9VXJ3gi8JbX2h0t8_MY1hBA@mail.gmail.com>
 <CAPz=2oF8C-JAny9eM_gNkzQDj1CDjGfoQ17rcHm5-N-hOFAhUg@mail.gmail.com>
 <CAPz=2oE7HBJo59ANsYoEwyJU3AbjXU1opu_p3MuYZbcja_LCAg@mail.gmail.com>
 <CAMkU=1wn1Hfm+wKxx1sRZ_hEVbt6M5yAVrxXYZA8+B8q2D7-Zg@mail.gmail.com>
 <CAPz=2oHb7W5QzBSt-aAkmFBwC7EAJGxV_0x5OKwA_QeMwZNtbQ@mail.gmail.com>
 <CAPz=2oEN1DRjhWLJNN112xO-vzSGff=Cqgs5oLw9W12y=NMtWw@mail.gmail.com>
 <CAPz=2oEgTA3ENcUGEFQKGug09gWDw7ixrOLXpK3FenTiPVcXxQ@mail.gmail.com>
 <CAPz=2oFaS-xeVdYuidrXV9zvp-+d+x713K52rdgfp09HaP+Q4A@mail.gmail.com>
From: Nicolas Charles <nicolas.charles@normation.com>
Message-ID: <71a5e04d-8f2f-385a-2789-c78bf780a622@normation.com>
Date: Mon, 28 Jan 2019 15:22:19 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: 
 <CAPz=2oFaS-xeVdYuidrXV9zvp-+d+x713K52rdgfp09HaP+Q4A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: fr
List-Id: <pgsql-performance.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-performance@lists.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-performance>
Precedence: bulk

Le 28/01/2019 à 15:03, Saurabh Nanda a écrit :
> An update. It seems (to my untrained eye) that something is wrong with 
> the second SSD in the RAID configuration. Here's my question on 
> serverfault related to what I saw with iostat - 
> https://serverfault.com/questions/951096/difference-in-utilisation-reported-by-iostat-for-two-identical-disks-in-raid1
>
> I've disabled RAID and rebooted the server to run the benchmarks with 
> client=1,4,8,12 with shared_buffers=8MB (default) vs 
> shared_buffers=2GB (optimised?) and will report back.
>
>
You should probably include the detailed hardware you are working on - 
especially for the SSD, the model can have a big impact, as well as its 
wear.


Nicolas