Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> Zeugswetter Andreas SB SD wrote:
> >>
> >> >> > One problem with O_SYNC would be, that the OS does not group writes any
> >> >> > more. So the code would need to eighter do it's own sorting and grouping
> >> >> > (256k) or use aio, or you won't be able to get the maximum out of the disks.
> >> >>
> >> >> Or just run multiple writer processes, which I believe is Oracle's
> >> >> solution.
> >> >
> >> > That does not help, since for O_SYNC the OS'es (those I know) do not group those
> >> > writes together. Oracle allows more than one writer to busy more than one disk(subsystem) and circumvent other
perprocess limitations (mainly on platforms without AIO).
> >>
> >> Yes, I think the best way would be to let the background process write a
> >> bunch of pages, then fsync() the files written to. If one tends to have
> >> many dirty buffers to the same file, this will group them together and
> >> the OS can optimize that. If one really has completely random access,
> >> then there is nothing to group.
> >
> > Agreed. This might force enough stuff out to disk the checkpoint/sync()
> > would be OK. Jan, have you tested this?
> >
>
> As said, not using fsync() but sync() at that place. This only makes a
> real difference when you're not running PostgreSQL on a dedicated
> server. And yes, it really works well.
I talked to Jan about this. Basically, for testing, if sync decreases
the checkpoint load, fsync/O_SYNC should do even better, hopefully, once
he has that implemented.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
