Re: further testing on IDE drives

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: further testing on IDE drives
Дата
Msg-id Pine.LNX.4.33.0310021728040.25569-100000@css120.ihs.com
обсуждение исходный текст
Ответ на further testing on IDE drives  ("scott.marlowe" <scott.marlowe@ihs.com>)
Ответы Re: further testing on IDE drives  (Bruce Momjian <pgman@candle.pha.pa.us>)
Update performance doc  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-performance
On Thu, 2 Oct 2003, scott.marlowe wrote:

> I was testing to get some idea of how to speed up the speed of pgbench
> with IDE drives and the write caching turned off in Linux (i.e. hdparm -W0
> /dev/hdx).
>
> The only parameter that seems to make a noticeable difference was setting
> wal_sync_method = open_sync.  With it set to either fsync, or fdatasync,
> the speed with pgbench -c 5 -t 1000 ran from 11 to 17 tps.  With open_sync
> it jumped to the range of 45 to 52 tps.  with write cache on I was getting
> 280 to 320 tps.  so, not instead of being 20 to 30 times slower, I'm only
> about 5 times slower, much better.
>
> Now I'm off to start a "pgbench -c 10 -t 10000" and pull the power cord
> and see if the data gets corrupted with write caching turned on, i.e. do
> my hard drives have the ability to write at least some of their cache
> during spin down.

OK, back from testing.

Information:  Dual PIV system with a pair of 80 gig IDE drives, model
number: ST380023A (seagate).  File system is ext3 and is on a seperate
drive from the OS.

These drives DO NOT write cache when they lose power.  Testing was done by
issuing a 'hdparm -W0/1 /dev/hdx' command where x is the real drive
letter, and 0 or 1 was chosen in place of 0/1.  Then I'd issue a 'pgbench
-c 50 -t 100000000' command, wait for a few minutes, then pull the power
cord.

I'm running RH linux 9.0 stock install, kernel: 2.4.20-8smp.

Three times pulling the plug with 'hdparm -W0 /dev/hdx' resulted in a
machine that would boot up, recover with journal, and a database that came
up within about 30 seconds, with all the accounts still intact.

Switching the caching back on with 'hdparm -W1 /dev/hdx' and doing the
same 'pgbench -c 50 -t 100000000' resulted in a corrupted database each
time.

Also, I tried each of the following fsync methods: fsync, fdatasync, and
open_sync with write caching turned off.  Each survived a power off test
with no corruption of the database.  fsync and fdatasync result in 11 to
17 tps with 'pgbench -c 5 -t 500' while open_sync resulted in 45 to 55
tps, as mentioned in the previous post.

I'd be interested in hearing from other folks which sync method works
for them and whether or not there are any IDE drives out there that can
write their cache to the platters on power off when caching is enabled.


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

Предыдущее
От: Dror Matalon
Дата:
Сообщение: Re: count(*) slow on large tables
Следующее
От: Gaetano Mendola
Дата:
Сообщение: Re: runtime of the same query in function differs on 2 degree!