Re: WAL and commit_delay

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL and commit_delay
Дата
Msg-id 6402.982450579@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL and commit_delay  (Larry Rosenman <ler@lerctr.org>)
Ответы Re: WAL and commit_delay  (Brent Verner <brent@rcfile.org>)
Список pgsql-hackers
Larry Rosenman <ler@lerctr.org> writes:
> I've written swap files and such with:
> dd if=/dev/zero of=SWAPFILE bs=512 count=204800
> and all the blocks are allocated. 

I've also confirmed that writing zeroes is sufficient on HPUX (du
shows that the correct amount of space is allocated, unlike the
current seek-to-the-end method).

Some poking around the net shows that pre-2.4 Linux kernels implement
fdatasync() as fsync(), and we already knew that BSD hasn't got it
at all.  So distinguishing fdatasync from fsync won't be helpful for
very many people yet --- but I still think we should do it.  I'm
playing with a test setup in which I just changed pg_fsync to call
fdatasync instead of fsync, and on HPUX I'm seeing pgbench tps values
around 17, as opposed to 13 yesterday.  (The HPUX man page warns that
these calls are inefficient for large files, and I wouldn't be surprised
if a lot of the run time is now being spent in the kernel scanning
through all the buffers that belong to the logfile.  2.4 Linux is
apparently reasonably smart about this case, and only looks at the
actually dirty buffers.)

Is anyone out there running a 2.4 Linux kernel?  Would you try pgbench
with current sources, commit_delay=0, -B at least 1024, no -F, and see
how the results change when pg_fsync is made to call fdatasync instead
of fsync?  (It's in src/backend/storage/file/fd.c)
        regards, tom lane


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

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: Re: WAL and commit_delay
Следующее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: WAL and commit_delay