From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Doug Fields <dfields-pg-general(at)pexicom(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, Glenn Stone <gstone(at)pogolinux(dot)com> |
Subject: | Re: WAL recycling, Linux 2.4.18 |
Date: | 2002-07-08 20:12:09 |
Message-ID: | 26552.1026159129@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Doug Fields <dfields-pg-general(at)pexicom(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Doug Fields | 2002-07-08 20:24:15 | Re: WAL recycling, Linux 2.4.18 |
Previous Message | Doug Fields | 2002-07-08 20:00:48 | Re: WAL recycling, Linux 2.4.18 |