I see that one can now get compact flash to SATA connectors.

If I were to use a filesystem with noatime etc and little non-sql traffic,
does the physical update pattern tend to have hot sectors that will tend to
wear out CF?

I'm wondering about a RAID5 with data on CF drives and RAID1 for teh WAL on
a fast SATA or SAS drive pair. I'm thhinking that this would tend to have
good performance because the seek time for the data is very low, even if the
actual write speed can be slower than state of the art. 2GB CF isn't so
pricey any more.

Just wondering.

James

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.7/711 - Release Date: 05/03/2007
09:41


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On 3/7/07, James Mansion <james@mansionfamily.plus.com> wrote:
> I see that one can now get compact flash to SATA connectors.
>
> If I were to use a filesystem with noatime etc and little non-sql traffic,
> does the physical update pattern tend to have hot sectors that will tend to
> wear out CF?
>
> I'm wondering about a RAID5 with data on CF drives and RAID1 for teh WAL on
> a fast SATA or SAS drive pair. I'm thhinking that this would tend to have
> good performance because the seek time for the data is very low, even if the
> actual write speed can be slower than state of the art. 2GB CF isn't so
> pricey any more.
>
> Just wondering.

me too. I think if you were going to do this I would configure as
raid 0. Sequential performance might be a problem, and traditional
hard drive failure is not. I think some of the better flash drives
spread out the writes so that life is maximized.

It's still probably cheaper buying a better motherboard and stuffing
more memory in it, and a good raid controller.

merlin

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

* James Mansion:

> If I were to use a filesystem with noatime etc and little non-sql traffic,
> does the physical update pattern tend to have hot sectors that will tend to
> wear out CF?

Thanks to the FAT file system and its update pattern, most (if not
all) CF disks implement wear leveling nowadays. I wouldn't worry
about the issue, unless your write rates are pretty high.

--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

At 05:18 PM 3/6/2007, James Mansion wrote:
>I see that one can now get compact flash to SATA connectors.
>
>If I were to use a filesystem with noatime etc and little non-sql traffic,
>does the physical update pattern tend to have hot sectors that will tend to
>wear out CF?
Most flash RAMs have drivers that make sure the pattern of writes
over time is uniform across the entire device.


>I'm wondering about a RAID5 with data on CF drives and RAID1 for the WAL on
>a fast SATA or SAS drive pair. I'm thinking that this would tend to have
>good performance because the seek time for the data is very low, even if the
>actual write speed can be slower than state of the art.

WARNING: modern TOtL flash RAMs are only good for ~1.2M writes per
memory cell. and that's the =good= ones.
Using flash RAM for write heavy applications like OLTP, or for WAL,
etc can be very dangerous
Flash write speeds also stink; being ~1/2 flash's already low read speed.

Much better to use flash RAM for read heavy applications.
Even there you have to be careful that seek performance, not
throughput, is what is gating your day to day performance with those tables.

Got tables or indexes that are
a= too big to fit in RAM and
b= are write few, read many times and
c= whose pattern of access is large enough that it does not cache well?
=Those= are what should be put into flash RAMs


Side Note:
In the long run, we are going to have to seriously rethink pg's use
of WAL as the way we implement MVCC as it becomes more and more of a
performance bottleneck.
We have WAL because Stonebreaker made an assumption about the future
dominance of optical media that has turned out to be false.
....and it's been one of pg's big issues every since.


> 2GB CF isn't so
>pricey any more.
Heck =16= GB Flash only costs ~$300 US and 128GB SSDs based on flash
RAM are due out this year.


Cheers,
Ron



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

>
> Much better to use flash RAM for read heavy applications.
> Even there you have to be careful that seek performance, not
> throughput, is what is gating your day to day performance with those
> tables.


Isn't precisely there where Flash disks would have *the* big advantage??

I mean, access time is severely held down by the *mechanical* movement of
the heads to the right cylinder on the disk --- that's a brutally large
amount of
time compared to anything else happening on the computer (well, floppy
disks aside, and things like trying-to-break-128-bit-encryption aside
:-)).

Or are these Flash disks so slow that they compare to the HD's latency
figures?

Carlos
--


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

> Or are these Flash disks so slow that they compare to the HD's latency
> figures?

On sequential read speed HDs outperform flash disks... only on random
access the flash disks are better. So if your application is a DW one,
you're very likely better off using HDs.

Cheers,
Csaba.



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Le mardi 6 mars 2007 23:18, James Mansion a écrit*:
> I see that one can now get compact flash to SATA connectors.
I can suggest you to have a look at Gigabyte i-ram .
We use it on a website with higth traffic with lot of succes. Unfortunely, I
can not provide any benchmark...
>
> If I were to use a filesystem with noatime etc and little non-sql traffic,
> does the physical update pattern tend to have hot sectors that will tend to
> wear out CF?
>
> I'm wondering about a RAID5 with data on CF drives and RAID1 for teh WAL on
> a fast SATA or SAS drive pair. I'm thhinking that this would tend to have
> good performance because the seek time for the data is very low, even if
> the actual write speed can be slower than state of the art. 2GB CF isn't
> so pricey any more.
>
> Just wondering.
>
> James
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.446 / Virus Database: 268.18.7/711 - Release Date: 05/03/2007
> 09:41
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

>WARNING: modern TOtL flash RAMs are only good for ~1.2M writes per
>memory cell. and that's the =good= ones.
>Using flash RAM for write heavy applications like OLTP, or for WAL,
>etc can be very dangerous

Well, that's why I suggested that the WAL would stream to a hard disk
array, where the large IO sequential write speed will be helpful.

Whether OLTP is a problem will presumably depend on the freqency of updates
and vacuum to each physical cluster of rows in a disk block.

Most rows in a trading application will have quite a long lifetime, and be
updated relatively few times (even where we writing fixings info into
trades).

>Flash write speeds also stink; being ~1/2 flash's already low read speed.

Sure - but it may still be an effective tradoff where the limiting factor
would otherwise be seek time.

>Much better to use flash RAM for read heavy applications.

Why? I can get a 'PC' server with 128GB of RAM quite easily now,
and that will mean I can cache most of not all hot data for any trading
app I've worked on. Settled trades that matured in prior periods can
be moved to tables on real disks - they are hardly ever accessed
anyway.


In the long run, we are going to have to seriously rethink pg's use
of WAL as the way we implement MVCC as it becomes more and more of a
performance bottleneck.
We have WAL because Stonebreaker made an assumption about the future
dominance of optical media that has turned out to be false.
....and it's been one of pg's big issues every since.


>> 2GB CF isn't so
>>pricey any more.
>Heck =16= GB Flash only costs ~$300 US and 128GB SSDs based on flash
>RAM are due out this year.

Quite. Suppose I have a RAID with double redundancy, then I get enough
capacity
for quite a lot of raw data, and can swap a card out every weekend and let
the
RAID rebuild it in rotation to keep them within conservative wear limits.

So long as the wear levelling works moderately well (and without needing FAT
on the disk or whatever) then I should be fine.

I think. Maybe.

James

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.7/713 - Release Date: 07/03/2007
09:24


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Thu, Mar 08, 2007 at 06:24:35AM -0000, James Mansion wrote:
>
> In the long run, we are going to have to seriously rethink pg's use
> of WAL as the way we implement MVCC as it becomes more and more of a
> performance bottleneck.
> We have WAL because Stonebreaker made an assumption about the future
> dominance of optical media that has turned out to be false.
> ...and it's been one of pg's big issues every since.

Uh. pg didn't *have* WAL back when Stonebreaker was working on it. It
was added in PostgreSQL 7.1, by Vadim. And it significantly increased
performance at the time, since we no longer had to sync the datafiles
after every transaction commit.
(We also didn't have MVCC back in the Stonebreaker days - it was added
in 6.5)

That said, it's certainly possible that someone can find an even better
way to do it :-)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On 3/8/07, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Mar 08, 2007 at 06:24:35AM -0000, James Mansion wrote:
> >
> > In the long run, we are going to have to seriously rethink pg's use
> > of WAL as the way we implement MVCC as it becomes more and more of a
> > performance bottleneck.
> > We have WAL because Stonebreaker made an assumption about the future
> > dominance of optical media that has turned out to be false.
> > ...and it's been one of pg's big issues every since.
>
> Uh. pg didn't *have* WAL back when Stonebreaker was working on it. It
> was added in PostgreSQL 7.1, by Vadim. And it significantly increased
> performance at the time, since we no longer had to sync the datafiles
> after every transaction commit.
> (We also didn't have MVCC back in the Stonebreaker days - it was added
> in 6.5)

Exactly, and WAL services other purposes than minimizing the penalty
from writing to high latency media. WAL underlies PITR for example.

Near-zero latency media is coming, eventually...and I don't think the
issue is reliability (catastrophic failure is extremely unlikely) but
cost. I think the poor write performance is not an issue because you
can assemble drives in a giant raid 0 (or even 00 or 000) which will
blow away disk based raid 10 systems at virtually everything.

Solid State Drives consume less power (a big deal in server farms) and
the storage density and life-span will continue to improve. I give it
five years (maybe less) before you start to see SSD penetration in a
big way. It will simply become cheaper to build a box with SSD than
without since you won't need to buy as much RAM, draws less power, and
is much more reliable.

Disk drives will displace tape as low speed archival storage but will
probably live on in super high storage enterprise environments.

my 0.02$, as usual,
merlin

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster