Re: compact flash disks?

От: Ron
Тема: Re: compact flash disks?
Дата: ,
Msg-id: E1HOxqf-0005Mn-Uw@elasmtp-kukur.atl.sa.earthlink.net
(см: обсуждение, исходный текст)
Ответ на: compact flash disks?  ("James Mansion")
Ответы: Re: compact flash disks?  (Carlos Moreno)
Re: compact flash disks?  ("James Mansion")
Список: pgsql-performance

Скрыть дерево обсуждения

compact flash disks?  ("James Mansion", )
 Re: compact flash disks?  ("Merlin Moncure", )
 Re: compact flash disks?  (Florian Weimer, )
 Re: compact flash disks?  (Ron, )
  Re: compact flash disks?  (Carlos Moreno, )
   Re: compact flash disks?  (Csaba Nagy, )
    Re: compact flash disks?  ("James Mansion", )
     postgresql.conf file for PostgreSQL 8.2.3  (Eugene Ogurtsov, )
  Re: compact flash disks?  ("James Mansion", )
   Re: compact flash disks?  (Magnus Hagander, )
    Re: compact flash disks?  ("Merlin Moncure", )
    Re: compact flash disks?  ("James Mansion", )
  Re: compact flash disks?  (Ron, )
   Re: compact flash disks?  ("Merlin Moncure", )
    Question about PGSQL functions  (Steve, )
     Re: Question about PGSQL functions  (Heikki Linnakangas, )
      Re: Question about PGSQL functions  (Steve, )
 Re: compact flash disks?  (cedric, )

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




В списке pgsql-performance по дате сообщения:

От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: [kris@obsecurity.org: Progress on scaling of FreeBSD on 8 CPU systems]
От: Zoolin Lin
Дата:
Сообщение: Re: Any advantage to integer vs stored date w. timestamp