From: Jesper Krogh <jesper@krogh.cc>
To: pgsql-performance@postgresql.org
Subject: Re: Intel SSDs that may not suck
Date: Tue, 29 Mar 2011 18:12:25 +0200
Message-ID: <4D9204E9.1060403@krogh.cc> (raw)
In-Reply-To: <8BE8F356-319F-4BE7-BE66-F45D50235985@torgo.978.org>
References: <4D90EDB6.2080609@2ndQuadrant.com>
<535760.62572.qm@web111307.mail.gq1.yahoo.com>
<AANLkTikGU9Dmo3bnh4vCn4L5q9u3efEH0-ZkwECzLwO8@mail.gmail.com>
<8BE8F356-319F-4BE7-BE66-F45D50235985@torgo.978.org>
On 2011-03-29 16:16, Jeff wrote:
> halt for 0.5-2 seconds, then resume. The fix we're going to do is
> replace each drive in order with the rebuild occuring between each.
> Then we do a security erase to reset the drive back to completely
> empty (including the "spare" blocks kept around for writes).
Are you replacing the drives with new once, or just secure-erase and
back in?
What kind of numbers are you drawing out of smartmontools in usage figures?
(Also seeing some write-stalls here, on 24 Raid50 volumes of x25m's, and
have been planning to cycle drives for quite some time, without actually
getting to it.
> Now that all sounds awful and horrible until you get to overall
> performance, especially with reads - you are looking at 20k random
> reads per second with a few disks. Adding in writes does kick it
> down a noch, but you're still looking at 10k+ iops. That is the
> current trade off.
Thats also my experience.
--
Jesper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jesper@krogh.cc
Subject: Re: Intel SSDs that may not suck
In-Reply-To: <4D9204E9.1060403@krogh.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox