Re: SSD + RAID - Mailing list pgsql-performance

On Thu, 2009-11-19 at 19:01 +0100, Anton Rommerskirchen wrote:
> Am Donnerstag, 19. November 2009 13:29:56 schrieb Craig Ringer:
> > On 19/11/2009 12:22 PM, Scott Carey wrote:
> > > 3:  Have PG wait a half second (configurable) after the checkpoint
> > > fsync() completes before deleting/ overwriting any WAL segments.  This
> > > would be a trivial "feature" to add to a postgres release, I think.
> >
> > How does that help? It doesn't provide any guarantee that the data has
> > hit main storage - it could lurk in SDD cache for hours.
> >
> > > 4: Yet another solution:  The drives DO adhere to write barriers
> > > properly. A filesystem that used these in the process of fsync() would be
> > > fine too. So XFS without LVM or MD (or the newer versions of those that
> > > don't ignore barriers) would work too.
> >
> > *if* the WAL is also on the SSD.
> >
> > If the WAL is on a separate drive, the write barriers do you no good,
> > because they won't ensure that the data hits the main drive storage
> > before the WAL recycling hits the WAL disk storage. The two drives
> > operate independently and the write barriers don't interact.
> >
> > You'd need some kind of inter-drive write barrier.
> >
> > --
> > Craig Ringer
>
>
> Hello !
>
> as i understand this:
> ssd performace is great, but caching is the problem.
>
> questions:
>
> 1. what about conventional disks with 32/64 mb cache ? how do they handle the
> plug test if their caches are on ?

If the aren't battery backed, they can lose data.  This is not specific
to SSD.

> 2. what about using seperated power supply for the disks ? it it possible to
> write back the cache after switching the sata to another machine controller ?

Not sure.  I only use devices with battery backed caches or no cache.  I
would be concerned however about the drive not flushing itself and still
running out of power.

> 3. what about making a statement about a lacking enterprise feature (aka
> emergency battery equipped ssd) and submitting this to the producers ?

The producers aren't making Enterprise products, they are using caches
to accelerate the speeds of consumer products to make their drives more
appealing to consumers.  They aren't going to slow them down to make
them more reliable, especially when the core consumer doesn't know about
this issue, and is even less likely to understand it if explained.

They may stamp the word Enterprise on them, but it's nothing more than
marketing.

> I found that one of them (OCZ) seems to handle suggestions of customers (see
> write speed discussins on vertex fro example)
>
> and another (intel) seems to handle serious problems with his disks in
> rewriting and sometimes redesigning his products - if you tell them and
> market dictades to react (see degeneration of performace before 1.11
> firmware).
>
> perhaps its time to act and not only to complain about the fact.

Or, you could just buy higher quality equipment that was designed with
this in mind.

There is nothing unique to SSD here IMHO.  I wouldn't run my production
grade databases on consumer grade HDD, I wouldn't run them on consumer
grade SSD either.


--
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.