Re: understanding postgres issues/bottlenecks

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: david(at)lang(dot)hm
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Ron <rjpeace(at)earthlink(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: understanding postgres issues/bottlenecks
Date: 2009-01-10 19:00:59
Message-ID: 4968F06B.1020601@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi,

david(at)lang(dot)hm wrote:
> On Sat, 10 Jan 2009, Gregory Stark wrote:
>> I think the idea is that with SSDs or a RAID with a battery backed
>> cache you
>> can leave fsync on and not have any significant performance hit since
>> the seek
>> times are very fast for SSD. They have limited bandwidth but bandwidth
>> to the
>> WAL is rarely an issue -- just latency.

That's also my understanding.

> with SSDs having extremely good read speeds, but poor (at least by
> comparison) write speeds I wonder if any of the RAID controllers are
> going to get a mode where they cache writes, but don't cache reads,
> leaving all ofyour cache to handle writes.

My understanding of SSDs so far is, that they are not that bad at
writing *on average*, but to perform wear-leveling, they sometimes have
to shuffle around multiple blocks at once. So there are pretty awful
spikes for writing latency (IIRC more than 100ms has been measured on
cheaper disks).

A battery backed cache could theoretically flatten those, as long as
your avg. WAL throughput is below the SSDs avg. writing throughput.

Regards

Markus Wanner

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2009-01-10 19:10:44 Re: understanding postgres issues/bottlenecks
Previous Message Markus Wanner 2009-01-10 18:45:23 block device benchmarking