Re: WAL recycling, Linux 2.4.18

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL recycling, Linux 2.4.18
Дата
Msg-id 26552.1026159129@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL recycling, Linux 2.4.18  (Doug Fields <dfields-pg-general@pexicom.com>)
Ответы Re: WAL recycling, Linux 2.4.18  (Doug Fields <dfields-pg-general@pexicom.com>)
Список pgsql-general
Doug Fields <dfields-pg-general@pexicom.com> writes:
> FSYNC=OFF results:
> What a difference. My checkpoints are just as long - they still take quite
> a bit of time to process and do a lot of "blocks out" on the vmstat - but
> queries now longer block waiting for them to finish.

This is beginning to look like a kernel problem.

> FSYNCA - gives runtime error: FATAL 1:  invalid value for option
> 'WAL_SYNC_METHOD': 'FSYNCA'
> and refuses to start

That should be FSYNC not FSYNCA, I believe.

> Of note, in the fdatasync() man page:        Currently (Linux 2.2)
> fdatasync is equivalent to fsync.

Are you really using a 2.2 kernel?  I thought that that point had been
fixed in 2.4 kernels.  (I see the comment is still there in the man page
on my RH7.2 box, though.)


Now that we've eliminated MoveOfflineLogs as the time-consuming part of
checkpoint, would you make the same check for mdsync()?  That's the
routine that actually issues the sync() calls.  Again, it would be
useful to know how long it takes, and whether the other backends appear
to be blocked at the times mdsync() is entered and exited.

            regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WAL recycling, Linux 2.4.18
Следующее
От: "Carmen Wai"
Дата:
Сообщение: LOAD command not updating the recompiled object code