Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1agvit-0002ib-3P for pgsql-performance@arkaria.postgresql.org; Fri, 18 Mar 2016 14:49:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1agvis-00032v-Gr for pgsql-performance@arkaria.postgresql.org; Fri, 18 Mar 2016 14:49:54 +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 1agvhC-00014l-0s for pgsql-performance@postgresql.org; Fri, 18 Mar 2016 14:48:10 +0000 Received: from mail-ob0-x22b.google.com ([2607:f8b0:4003:c01::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1agvh9-0003HP-4P for pgsql-performance@postgresql.org; Fri, 18 Mar 2016 14:48:08 +0000 Received: by mail-ob0-x22b.google.com with SMTP id fp4so118261874obb.2 for ; Fri, 18 Mar 2016 07:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5OjOwXXnuusbhXTr3VtNop2CczCnikiOvbmpSneJnlA=; b=spAhE1/dVyZeRWJeICVK45jLYRdQpwgqGkTlSK35GXyyppnmbbBJSWIO3hwLeKXagJ KWNGJQ9giAXVza/TaKLBwLlCaof8BpBnw2ms7Uu1nCVDbtHoA/9hHKqTgIO1r/TCqh08 L7t5c8awz2JiwkJh7in93m1eRbzgZ1ZJyhbYmwCq7WOeupsX+0HFKqTuN3KoChq9zLAy JXJX8Da9vBE57CVjSr1dSC2SyN/QawmaWFEBCVA9bsgzwm//Fppg//Q+HOkrQV92DhnQ VOJ1yW2vcOqz259YDb47u7P3u8jz9SJ9UAvB5llsJxiEzcayoYyQKm3b9ymGqMfxFBCp cTXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5OjOwXXnuusbhXTr3VtNop2CczCnikiOvbmpSneJnlA=; b=d8JVC4y1ojEReotFsz6Eo+Veas21uMcGNOx8JjvuT47E5jjoqxi0HcPqsBvxoOd38m +3O7q7uCIBKRQa7FCQwi/ZL3UK48Pu4QEJXXdImpEsdijrnMxiOS29l2mii7m98Mh8Cs y3m6QXjC0ps6XEKDb8SOIco0Ay7Uy+7kT0c4+A1NdA3MypV32fKHD+O6EL9EEADMow8g UQKcBk3fYBqLCGmFBfQ+afA3gcnIPOEEYkX97PPAUmguZJ1zdfDEG5CkRgQgJOqfOIl6 7Psa3mXegmyDRyM8taNL0bvVpLdOSfuo7tEaKspBzRw7/yErC8is6qLjLSyYjhQO06qN l21A== X-Gm-Message-State: AD7BkJKmseYPNMLnQ15C1QVSdsLwL0c2sUFisNPPF/P6JLtLlBK5Be4ORocKQPEFdl84rCUs994JK47FYmfq1Q== MIME-Version: 1.0 X-Received: by 10.60.140.168 with SMTP id rh8mr10665305oeb.9.1458312486378; Fri, 18 Mar 2016 07:48:06 -0700 (PDT) Received: by 10.76.141.9 with HTTP; Fri, 18 Mar 2016 07:48:06 -0700 (PDT) In-Reply-To: <01da01d18091$8d991c50$a8cb54f0$@runbox.com> References: <01da01d18091$8d991c50$a8cb54f0$@runbox.com> Date: Fri, 18 Mar 2016 10:48:06 -0400 Message-ID: Subject: Re: Disk Benchmarking Question From: Dave Stibrany To: Mike Sofen Cc: pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=047d7b2e4c46b8e493052e53d511 X-Pg-Spam-Score: -2.7 (--) 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 --047d7b2e4c46b8e493052e53d511 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Mike, Thanks for the response. I think where I'm confused is that I thought vendor specified MBps was an estimate of sequential read/write speed. Therefore if you're in RAID10, you'd have 4x the sequential read speed and 2x the sequential write speed. Am I misunderstanding something? Also, when you mention that MBPs is the capacity of the interface, what do you mean exactly. I've been taking interface speed to be the electronic transfer speed, not the speed from the actual physical medium, and more in the 6-12 gigabit range. Please let me know if I'm way off on any of this, I'm hoping to have my mental model updated. Thanks! Dave On Thu, Mar 17, 2016 at 5:11 PM, Mike Sofen wrote: > 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). Most db disk benchmarks revolve arou= nd > 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 10 so yo= u > 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. > > > > 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 rai= d > 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 t= o the > capacity limit of the write cache. With only 400 iops of write speed, wi= th > 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 clar= ify for > me. > > > > Mike > > > > *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 > > > > 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 /, an= d > 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 > > https://www.dropbox.com/s/pwe2g5ht9fpjl2j/bonnie.today.html?dl=3D0 > > > > 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 > > > > > > > --=20 *THIS IS A TEST* --047d7b2e4c46b8e493052e53d511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Mike,

Thanks for the response. I th= ink where I'm confused is that I thought vendor specified MBps was an e= stimate of sequential read/write speed. Therefore if you're in RAID10, = you'd have 4x the sequential read speed and 2x the sequential write spe= ed. Am I misunderstanding something?

Also, when yo= u mention that MBPs is the capacity of the interface, what do you mean exac= tly. I've been taking interface speed to be the electronic transfer spe= ed, not the speed from the actual physical medium, and more in the 6-12 gig= abit range.

Please let me know if I'm way off = on any of this, I'm hoping to have my mental model updated.
<= br>
Thanks!

Dave

On Thu, Mar 17, 2016 at 5:1= 1 PM, Mike Sofen <msofen@runbox.com> wrote:
<= p class=3D"MsoNormal">Hi Dave,

=C2=A0

Database disk p= erformance 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 (usu= ally) versus writing giant globs, especially in direct attached storage (li= ke yours, versus a SAN).=C2=A0 Most db disk benchmarks revolve around IOPs= =E2=80=A6and this is where SSDs utterly crush spinning disks.=

=C2=A0

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 (l= ike the Samsung 850 pro) will support a minimum of 40k IOPs on reads and 80= k IOPs on writes.=C2=A0 That=E2=80=99s why SSDs are eliminating spinning di= sks when performance is critical and budget allows.

=C2=A0

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 a= nd then your system will drop to a crawl.

=C2=A0

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

=C2=A0<= /span>

Mike

=C2=A0

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

=C2= =A0

I'm pretty new to benchm= arking hard disks and I'm looking for some advice on interpreting the r= esults of some basic tests.

=C2=A0

The server is= :

- Dell PowerEdge R430<= u>

- 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.

=C2=A0

<= p class=3D"MsoNormal">The OS is Ubuntu 14.04, I'm using LVM and I have = an ext4 volume for /, and an xfs volume for PGDATA.

=

=C2=A0

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

=C2=A0

=

Here's a link to the bonnie test results<= u>

=C2=A0

The vendor stats say sustained throughput of 215 to 10= 8 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 s= equential speeds are almost identical. Does this look wrong?<= /p>

=C2=A0

Thanks,

=C2=A0

Dave

=C2=A0

=C2=A0

=C2=A0




--
THIS IS A TEST
--047d7b2e4c46b8e493052e53d511--