Re: Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery
Дата
Msg-id Pine.GSO.4.64.0708222328350.14539@westnet.com
обсуждение исходный текст
Ответ на Postgres, fsync and RAID controller with 100M of internal cache & dedicated battery  ("Dmitry Koterov" <dmitry@koterov.ru>)
Список pgsql-general
On Wed, 22 Aug 2007, Dmitry Koterov wrote:

> We are trying to use HP CISS contoller (Smart Array E200i)

There have been multiple reports of problems with general performance
issues specifically with the cciss Linux driver for other HP cards.  The
E200i isn't from the same series, but I wouldn't expect that their drivers
have gotten much better.  Wander through the thread at
http://svr5.postgresql.org/pgsql-performance/2006-07/msg00257.php to see
one example I recall from last year; there are more in the archives if you
search around a bit.

> I have written a small perl script to check how slow is fsync for Smart
> Array E200i controller. Theoretically, because of write cache, fsync MUST
> cost nothing, but in practice it is not true:
>>>> fsync took 0.247033 s

For comparision sake, your script run against my system with an Areca
ARC-1210 card with 256MB of cache 20 times gives me the following minimum
and maximum times (full details on my server config are at
http://www.westnet.com/~gsmith/content/postgresql/serverinfo.htm ):

>>> fsync took 0.039676 s
>>> fsync took 0.041137 s

And here's what the last set of test_fsync results look like on my system:

Compare file sync methods with 2 8k writes:
         open o_sync, write       0.099819
         write, fdatasync         0.100054
         write, fsync,            0.094009

So basically your card is running 3 (test_fsync) to 6 (your script) times
slower than my Areca unit on these low-level tests.  I don't know that
it's possible to drive the fsync times completely to zero, but there's
certainly a whole lot of improvement from where you are to what I'd expect
from even a cheap caching controller like I'm using.  I've got maybe $900
worth of hardware total in this box and it's way faster than yours in this
area.

> (Also, I tried to manually specify open_sync method in postgresql.conf,
> but after that Postgres database had completely crashed. :-)

This is itself a sign there's something really strange going on.  There's
something wrong with your system, your card, or the OS/driver you're using
if open_sync doesn't work under Linux; in fact, it should be faster in
practice even if it looks a little slower on test_fsync.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump causes postgres crash
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: %TYPE