Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1agfF7-0001Nd-No for pgsql-performance@arkaria.postgresql.org; Thu, 17 Mar 2016 21:14:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1agfF7-0002Po-8Z for pgsql-performance@arkaria.postgresql.org; Thu, 17 Mar 2016 21:14:05 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1agfDQ-0007YY-Kk for pgsql-performance@postgresql.org; Thu, 17 Mar 2016 21:12:20 +0000 Received: from aibo.runbox.com ([91.220.196.211]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1agfDM-0004u0-Kt for pgsql-performance@postgresql.org; Thu, 17 Mar 2016 21:12:19 +0000 Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1agfDE-0000Y2-0O; Thu, 17 Mar 2016 22:12:08 +0100 Received: from rrcs-74-87-24-164.west.biz.rr.com ([74.87.24.164] helo=seasyslap4) by mailfront10.runbox.com with esmtpsa (uid:561468 ) (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.82) id 1agfCd-0006PP-Lv; Thu, 17 Mar 2016 22:11:32 +0100 From: "Mike Sofen" To: "'Dave Stibrany'" , References: In-Reply-To: Subject: Re: Disk Benchmarking Question Date: Thu, 17 Mar 2016 14:11:17 -0700 Message-ID: <01da01d18091$8d991c50$a8cb54f0$@runbox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DB_01D18056.E13B2EB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI0k5eacQMu4dP4xLoYYyMzqTGyy56X9q1w Content-Language: en-us X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org This is a multipart message in MIME format. ------=_NextPart_000_01DB_01D18056.E13B2EB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, =20 Database disk performance has to take into account IOPs, and IMO, over = MBPs, since it=E2=80=99s the ability of the disk subsystem to write lots = of little bits (usually) versus writing giant globs, especially in = direct attached storage (like yours, versus a SAN). Most db disk = benchmarks revolve around IOPs=E2=80=A6and this is where SSDs utterly = crush spinning disks. =20 You can get maybe 200 IOPs out of each disk, you have 4 in raid 10 so = you get a whopping 400 IOPs. A single quality SSD (like the Samsung 850 = pro) will support a minimum of 40k IOPs on reads and 80k IOPs on writes. = That=E2=80=99s why SSDs are eliminating spinning disks when performance = is critical and budget allows. =20 Back to your question =E2=80=93 the MBPs is the capacity of interface, = so it makes sense that it=E2=80=99s the same for both reads and writes. = The perc raid controller will be saving your bacon on writes, with 2gb = cache (assuming it=E2=80=99s caching writes), so it becomes the = equivalent of an SSD up to the capacity limit of the write cache. With = only 400 iops of write speed, with a busy server you can easily saturate = the cache and then your system will drop to a crawl. =20 If I didn=E2=80=99t answer the intent of your question, feel free to = clarify for me. =20 Mike =20 From: pgsql-performance-owner@postgresql.org = [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Dave = Stibrany Sent: Thursday, March 17, 2016 1:45 PM To: pgsql-performance@postgresql.org Subject: [PERFORM] Disk Benchmarking Question =20 I'm pretty new to benchmarking hard disks and I'm looking for some = advice on interpreting the results of some basic tests. =20 The server is: - Dell PowerEdge R430 - 1 x Intel Xeon E5-2620 2.4GHz - 32 GB RAM - 4 x 600GB 10k SAS Seagate ST600MM0088 in RAID 10 - PERC H730P Raid Controller with 2GB cache in write back mode. =20 The OS is Ubuntu 14.04, I'm using LVM and I have an ext4 volume for /, = and an xfs volume for PGDATA. =20 I ran some dd and bonnie++ tests and I'm a bit confused by the numbers. = I ran 'bonnie++ -n0 -f' on the root volume. =20 Here's a link to the bonnie test results https://www.dropbox.com/s/pwe2g5ht9fpjl2j/bonnie.today.html?dl=3D0 =20 The vendor stats say sustained throughput of 215 to 108 MBps, so I guess = I'd expect around 400-800 MBps read and 200-400 MBps write. In any case, = I'm pretty confused as to why the read and write sequential speeds are = almost identical. Does this look wrong? =20 Thanks, =20 Dave =20 =20 =20 ------=_NextPart_000_01DB_01D18056.E13B2EB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi = Dave,

 

Database = disk performance has to take into account IOPs, and IMO, over MBPs, = since it=E2=80=99s the ability of the disk subsystem to write lots of = little bits (usually) versus writing giant globs, especially in direct = attached storage (like yours, versus a SAN).=C2=A0 Most db disk = benchmarks revolve around IOPs=E2=80=A6and this is where SSDs utterly = crush spinning disks.

 

You can get = maybe 200 IOPs out of each disk, you have 4 in raid=C2=A0 10 so you get = a whopping 400 IOPs.=C2=A0 A single quality SSD (like the Samsung 850 = pro) will support a minimum of 40k IOPs on reads and 80k IOPs on = writes.=C2=A0 That=E2=80=99s why SSDs are eliminating spinning disks = when performance is critical and budget allows.

 

Back to your = question =E2=80=93 the MBPs is the capacity of interface, so it makes = sense that it=E2=80=99s the same for both reads and writes.=C2=A0 The = perc raid controller will be saving your bacon on writes, with 2gb cache = (assuming it=E2=80=99s caching writes), so it becomes the equivalent of = an SSD up to the capacity limit of the write cache.=C2=A0 With only 400 = iops of write speed, with a busy server you can easily saturate the = cache and then your system will drop to a crawl.

 

If I = didn=E2=80=99t answer the intent of your question, feel free to clarify = for me.

 

Mike

 

From:<= /b> = pgsql-performance-owner@postgresql.org = [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Dave = Stibrany
Sent: Thursday, March 17, 2016 1:45 PM
To: = pgsql-performance@postgresql.org
Subject: [PERFORM] Disk = Benchmarking Question

 

I'm pretty new to benchmarking hard disks and I'm = looking for some advice on interpreting the results of some basic = tests.

 

The server is:

- Dell PowerEdge R430

- 1 x Intel Xeon E5-2620 = 2.4GHz

- 32 GB = RAM

- 4 x 600GB 10k SAS = Seagate ST600MM0088 in RAID 10

- PERC H730P Raid Controller with 2GB cache in write = back mode.

 

The OS is Ubuntu 14.04, I'm using LVM and I have an = ext4 volume for /, and an xfs volume for = PGDATA.

 

I = ran some dd and bonnie++ tests and I'm a bit confused by the numbers. I = ran 'bonnie++ -n0 -f' on the root volume.

 

Here's a link to the bonnie test = results

 

The vendor stats say sustained throughput of 215 to = 108 MBps, so I guess I'd expect around 400-800 MBps read and 200-400 = MBps write. In any case, I'm pretty confused as to why the read and = write sequential speeds are almost identical. Does this look = wrong?

 

Thanks,

 

Dave

 

 

 

------=_NextPart_000_01DB_01D18056.E13B2EB0--