On Thu, Apr 3, 2014 at 4:00 PM, John R Pierce wrote:
> an important thing in getting decent wear leveling life with SSDs is to keep
> them under about 70% full.
You have to do that at provisioning time in the drive. Ie, once you
layer a file system on it, the drive doesn't know what's "empty" and
On 4/5/2014 8:13 AM, David Boreham wrote:
On 4/4/2014 5:29 PM, Lists wrote:
So, spend the money and get the enterprise class SSDs. They have come
down considerably in price over the last year or so. Although on
paper the Intel Enterprise SSDs tend to trail the performance numbers
of the leadin
On Sat, Apr 5, 2014 at 9:13 AM, David Boreham wrote:
> On 4/4/2014 5:29 PM, Lists wrote:
>>
>> So, spend the money and get the enterprise class SSDs. They have come down
>> considerably in price over the last year or so. Although on paper the Intel
>> Enterprise SSDs tend to trail the performance
On 4/4/2014 5:29 PM, Lists wrote:
So, spend the money and get the enterprise class SSDs. They have come
down considerably in price over the last year or so. Although on paper
the Intel Enterprise SSDs tend to trail the performance numbers of the
leading consumer drives, they have wear character
On Fri, Apr 4, 2014 at 5:20 PM, Scott Marlowe wrote:
> The real danger with consumer drives is they don't have supercaps and
> can and will therefore corrupt your data on power failure. The actual
> write cycles aren't a big deal for many uses, as now even consumer
> drives have very long write cy
On Fri, Apr 4, 2014 at 5:29 PM, Lists wrote:
> On 04/02/2014 02:55 PM, Bret Stern wrote:
>>
>> Care to share the SSD hardware you're using?
>>
>> I've used none to date, and have some critical data I would like
>> to put on a development server to test with.
>>
>> Regards,
>>
>> Bret Stern
>
>
> S
>
> It might be tempting to use a consumer-grade SSD due to the significant
> cost savings, but the money saved is vapor. They may be OK for a dev
> environment, but you *will* pay in downtime in a production environment.
> Unlike regular hard drives where the difference between consumer and
> ent
On 04/02/2014 02:55 PM, Bret Stern wrote:
Care to share the SSD hardware you're using?
I've used none to date, and have some critical data I would like
to put on a development server to test with.
Regards,
Bret Stern
SSDs are ridiculously cheap when you consider the performance
difference.
On 4/4/2014 3:57 PM, Steve Crawford wrote:
Judicious archiving allows us to keep our total OS+data storage
requirements under 100GB. Usually. So we should be able to easily stay
in the $500/drive price range (200GB S3700) and still have plenty of
headroom for wear-leveling.
One option I'm co
On 04/04/2014 10:15 AM, Merlin Moncure wrote:
2. Do I need both BBU on the RAID *and* capacitor on the SSD or just on one?
Which one? I'm suspecting capacitor on the SSD and write-through on the
RAID.
You need both. The capacitor protects the drive, the BBU protects the
raid controller.
?? In wr
On Friday, April 4, 2014, Scott Marlowe wrote:
> On Fri, Apr 4, 2014 at 1:18 PM, John R Pierce
> >
> wrote:
> > On 4/4/2014 12:08 PM, Scott Marlowe wrote:
> >>
> >> You don't technically need the BBU / flashback memory IF the
> >> controller is in write through.
> >
> >
> > if you HAVE the BBU/f
On Fri, Apr 4, 2014 at 1:18 PM, John R Pierce wrote:
> On 4/4/2014 12:08 PM, Scott Marlowe wrote:
>>
>> You don't technically need the BBU / flashback memory IF the
>> controller is in write through.
>
>
> if you HAVE the BBU/flash why would you put the controller in write
> through?? the whole P
On Fri, Apr 4, 2014 at 10:15 AM, Merlin Moncure wrote:
> For all around performance, the
> S3700 (2.5$/gb) IMO held the crown for most of 2013 and I think is
> still the one to buy. The s3500 (1.25$/gb) came out and also looks
> like a pretty good deal
The S3500 can be had for $1.00/GB now these
On 4/4/2014 12:08 PM, Scott Marlowe wrote:
You don't technically need the BBU / flashback memory IF the
controller is in write through.
if you HAVE the BBU/flash why would you put the controller in write
through?? the whole POINT of bbu/flashback is that you can safely
enable writeback cachi
On Fri, Apr 4, 2014 at 11:15 AM, Merlin Moncure wrote:
> On Fri, Apr 4, 2014 at 11:04 AM, Steve Crawford
> wrote:
>> On 04/03/2014 12:44 PM, Brent Wood wrote:
>> 2. Do I need both BBU on the RAID *and* capacitor on the SSD or just on one?
>> Which one? I'm suspecting capacitor on the SSD and wri
On 4/4/2014 10:15 AM, Merlin Moncure wrote:
2. Do I need both BBU on the RAID*and* capacitor on the SSD or just on one?
>Which one? I'm suspecting capacitor on the SSD and write-through on the
>RAID.
You need both. The capacitor protects the drive, the BBU protects the
raid controller.
note
On Fri, Apr 4, 2014 at 11:04 AM, Steve Crawford
wrote:
> On 04/03/2014 12:44 PM, Brent Wood wrote:
>
> Hi David,
My take:
> Does the RAID 1 array give any performance benefits over a single drive? I'd
> guess that writes may be slower, reads may be faster (if balanced) but data
> security is imp
It would be useful to know more details -- how much storage space you
need for example.
fwiw I considered all of these issues when we first deployed SSDs and
decided to not use RAID controllers.
There have not been any reasons to re-think that decision since.
However, it depends on your specif
On 04/03/2014 12:44 PM, Brent Wood wrote:
Hi David,
Does the RAID 1 array give any performance benefits over a single
drive? I'd guess that writes may be slower, reads may be faster (if
balanced) but data security is improved.
I've been looking into upgrading to SSD and wondering about RAID
On Thu, Apr 3, 2014 at 1:44 PM, Brent Wood wrote:
>
> Hi David,
>
> Does the RAID 1 array give any performance benefits over a single drive? I'd
> guess that writes may be slower, reads may be faster (if balanced) but data
> security is improved.
I did some testing on machines with 3xMLC Fusion
On Thu, Apr 3, 2014 at 3:28 PM, Merlin Moncure wrote:
> On Thu, Apr 3, 2014 at 2:53 PM, Scott Marlowe wrote:
>> On a machine with 16 cores with HT (appears as 32 cores) and 8 of the
>> 3700 series Intel SSDs in a RAID-10 under an LSI MegaRAID with BBU, I
>> was able to get 6300 to 7500 tps on a d
alf of David Rees [dree...@gmail.com]
Sent: Friday, April 4, 2014 8:32 AM
To: Merlin Moncure
Cc: bret_st...@machinemanagement.com; PostgreSQL General
Subject: Re: [GENERAL] SSD Drives
On Thu, Apr 3, 2014 at 12:13 PM, Merlin Moncure wrote:
> On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
>
On Thu, Apr 3, 2014 at 2:53 PM, Scott Marlowe wrote:
> On a machine with 16 cores with HT (appears as 32 cores) and 8 of the
> 3700 series Intel SSDs in a RAID-10 under an LSI MegaRAID with BBU, I
> was able to get 6300 to 7500 tps on a decent sized pgbench db
> (-s1000).
Did you happen to grab a
On 4/3/2014 2:00 PM, John R Pierce wrote:
an important thing in getting decent wear leveling life with SSDs is
to keep them under about 70% full.
This depends on the drive : drives with higher specified write endurance
already have significant overprovisioning, before the user sees the spa
On 4/3/2014 12:32 PM, David Rees wrote:
So yeah, even the slower, cheaper S3500 SSDs are way fast. If your
write workload isn't too high, the S3500 can work well. We'll see how
the SMART drive lifetime numbers do once we get into production, but
right now we estimate they should last at least 5 y
On Thu, 2014-04-03 at 12:32 -0700, David Rees wrote:
> On Thu, Apr 3, 2014 at 12:13 PM, Merlin Moncure wrote:
> > On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
> > wrote:
> >> Any opinions/comments on using SSD drives with postgresql?
> >
> > Here's a single S3700 smoking an array of 16 15k drives (
On Thu, Apr 3, 2014 at 1:32 PM, David Rees wrote:
> On Thu, Apr 3, 2014 at 12:13 PM, Merlin Moncure wrote:
>> On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
>> wrote:
>>> Any opinions/comments on using SSD drives with postgresql?
>>
>> Here's a single S3700 smoking an array of 16 15k drives (poster
On Thu, Apr 3, 2014 at 12:44 PM, Brent Wood wrote:
> Does the RAID 1 array give any performance benefits over a single drive? I'd
> guess
> that writes may be slower, reads may be faster (if balanced) but data
> security is improved.
Unfortunately I didn't test a single drive as that's not a
co
On Thu, Apr 3, 2014 at 12:13 PM, Merlin Moncure wrote:
> On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
> wrote:
>> Any opinions/comments on using SSD drives with postgresql?
>
> Here's a single S3700 smoking an array of 16 15k drives (poster didn't
> realize that; was to focused on synthetic numbers
On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
wrote:
> Any opinions/comments on using SSD drives with postgresql?
Here's a single S3700 smoking an array of 16 15k drives (poster didn't
realize that; was to focused on synthetic numbers):
http://dba.stackexchange.com/questions/45224/postgres-write-per
On Apr 3, 2014, at 12:47 PM, John R Pierce wrote:
> On 4/3/2014 9:26 AM, Joe Van Dyk wrote:
>> Related, anyone have any thoughts on using postgresql on Amazon's EC2 SSDs?
>> Been looking at
>> http://aws.amazon.com/about-aws/whats-new/2013/12/19/announcing-the-next-generation-of-amazon-ec2-hi
On 4/3/2014 9:26 AM, Joe Van Dyk wrote:
Related, anyone have any thoughts on using postgresql on Amazon's EC2
SSDs? Been looking at
http://aws.amazon.com/about-aws/whats-new/2013/12/19/announcing-the-next-generation-of-amazon-ec2-high-i/o-instance
if your data isn't very important, by all m
On Wed, Apr 2, 2014 at 12:37 PM, Bret Stern <
bret_st...@machinemanagement.com> wrote:
> Any opinions/comments on using SSD drives with postgresql?
>
Related, anyone have any thoughts on using postgresql on Amazon's EC2 SSDs?
Been looking at
http://aws.amazon.com/about-aws/whats-new/2013/12/19/a
While I have two friends who work at FusionIO, and have great confidence
in their products, we like to deploy more conventional SATA SSDs at
present in our servers. We have been running various versions of Intel's
enterprise and data center SSDs in production for several years now and
couldn'
We used 4x OCZ Deneva 2 in a RAID configuration. Worked well for us for
over 2 years with no hardware issues. We switched to SSD because we had
a very write-intensive application (30 million rows/day) that spinning
disks just couldn't keep up with.
On 4/2/2014 6:09 PM, Shaun Thomas wrote:
O
On Wed, Apr 2, 2014 at 4:09 PM, Shaun Thomas wrote:
> On 04/02/2014 04:55 PM, Bret Stern wrote:
>
>> Care to share the SSD hardware you're using?
>
>
> We use these:
>
> http://www.fusionio.com/products/iodrive2/
>
> The older versions of these cards can read faster than a RAID-10 of 80x15k
> RPM
On 04/02/2014 04:55 PM, Bret Stern wrote:
Care to share the SSD hardware you're using?
We use these:
http://www.fusionio.com/products/iodrive2/
The older versions of these cards can read faster than a RAID-10 of
80x15k RPM SAS drives, based on our tests from a couple yeas ago. Writes
aren'
Care to share the SSD hardware you're using?
I've used none to date, and have some critical data I would like
to put on a development server to test with.
Regards,
Bret Stern
On Wed, 2014-04-02 at 15:31 -0500, Shaun Thomas wrote:
> On 04/02/2014 02:50 PM, Brent Wood wrote:
>
> > http://it-blog
On 04/02/2014 02:50 PM, Brent Wood wrote:
http://it-blog.5amsolutions.com/2010/08/performance-of-postgresql-ssd-vs.html
While interesting, these results are extremely out of date compared to
current drives. Current chips and firmware regularly put out 2-10 times
better performance than even
AM
To: pgsql-general@postgresql.org
Subject: [GENERAL] SSD Drives
Any opinions/comments on using SSD drives with postgresql?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
<>
On 04/02/2014 02:37 PM, Bret Stern wrote:
Any opinions/comments on using SSD drives with postgresql?
Using SSDs with PostgreSQL is fine, provided they have an onboard
capacitor to ensure data integrity. The main concern with SSD drives, is
that they essentially lie about their sync status. T
Any opinions/comments on using SSD drives with postgresql?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
42 matches
Mail list logo