Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]

Поиск
Список
Период
Сортировка
От Guy Thornley
Тема Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
Дата
Msg-id 20061113083205.GJ29915@esphion.com
обсуждение исходный текст
Ответ на Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Ответы Re: Lying drives [Was: Re: Which OS provides the _fastest_  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-performance
> > That's not quite what I meant by "trust". Some drives lie about the
> > flush.
>
> Is that really true, or a misdiagnosed software bug?

I've yet to find a drive that lies about write completion. (*)

The problem is that the drives boot-up default is write-caching enabled (or
perhaps the system BIOS sets it that way).

If you turn an IDE disks write cache off explicity, using hdparm or similar,
they behave.

The problem, I think, is a bug in hdparm or the linux kernel: if you use the
little-'i' option, the output indicates the WC is disabled. However, if you
use big-'I' to actually interrogate the drive, you get the correct setting.

I tested this a while ago by writing a program that did fsync() to test
write latency and random-reads to test read latency, and then comparing
them.

- Guy

* I did experience a too-close-to-call case, where after write-cache was
  disabled, the write latency was the same as the read latency. For every
  other drive the write latency much, MUCH higher. However, before I
  disabled the WC, the write latency was a fraction of the read latency.

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

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: [BUGS] BUG #2737: hash indexing large table fails,while btree of same index works
Следующее
От: Cosimo Streppone
Дата:
Сообщение: Re: Context switch storm