Re: inferior SCSI performance

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: inferior SCSI performance
Дата
Msg-id 60brt1szby.fsf@dev6.int.libertyrms.info
обсуждение исходный текст
Ответ на Re: inferior SCSI performance  (Andrew Sullivan <andrew@libertyrms.info>)
Ответы Re: inferior SCSI performance  (Hannu Krosing <hannu@tm.ee>)
Список pgsql-performance
andrew@libertyrms.info (Andrew Sullivan) writes:
> On Wed, Oct 01, 2003 at 07:14:32AM -0600, scott.marlowe wrote:
>> FYI, on a Dual PIV2800 with 2 gig ram and a single UDMA 80 gig hard drive,
>> I from 420 tps to 22 tps when I disable write caching.  WOW.  A factor of
>> about 20 times slower.  (pgbench -c 4 -t 100)
>
> That's completely consistent with tests Chris Browne has done here on
> cache-enabled and cache-disabled boxes that we have.
>
> It's a _really_ big difference.  The combination of battery-backed
> write cache on your controller plus a real good UPS is quite possibly
> the number one thing you can do to improve performance.  For what
> it's worth, I can't see how this is something special about Postgres:
> even raw-filesystem type systems have to make sure the disk actually
> has the data, and a write cache is bound to be a big help for that.

Indeed.

When I ran the tests, I found that JFS was preferable to XFS and ext3
on Linux on the machine with the big battery backed cache.  (And the
side-effect that it was getting yes, probably about 20x the
performance of systems without the cache.)

The FS-related result appeared surprising, as the "stories" I had
heard suggested that JFS hadn't been particularly heavily tuned on
Linux, whereas XFS was supposed to be the "speed demon."

It is entirely possible that the result I saw was one that would
reverse partially or even totally on a system LACKING that cache.  XFS
might "play better" when we're cacheless; the (perhaps only fabled)
demerits of JFS being more than totally hidden if we add the cache.

What I find disappointing is that it isn't possible to get SSD cards
that are relatively inexpensive.  A similarly fabulous performance
increase _ought_ to be attainable if you could stick pg_xlog and
pg_clog on a 256MB (or bigger!) battery-backed SSD, ideally one that
plugs into a PCI slot.

This should have the further benefit of diminishing the amount of
mechanical activity going on, as WAL activity would no longer involve
ANY i/o operations.

Unfortunately, while there are companies hawking SSDs, they are in the
"you'll have to talk to our salescritter for pricing" category, which
means that they must be ferociously expensive.  :-(.
--
output = ("cbbrowne" "@" "libertyrms.info")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Joins on inherited tables
Следующее
От: Oleg Lebedev
Дата:
Сообщение: Re: TPC-R benchmarks