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
|
Список | 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 по дате отправления: