
> > 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 per process limitations (mainly on platforms without AIO). 

Andreas

Mon, 10 Nov 2003 18:42:44 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Experimental patch for inter-page delay in VACUUM
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 per process 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.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Mon, 10 Nov 2003 13:02:26 -0500
Jan Wieck <JanWieck@Yahoo.com>
Re: Experimental patch for inter-page delay in VACUUM
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 per process 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?

-- 
  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, Pennsylvania 19073

Mon, 10 Nov 2003 14:05:37 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Experimental patch for inter-page delay in VACUUM
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 per process 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.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


Mon, 10 Nov 2003 15:51:12 -0500
Jan Wieck <JanWieck@Yahoo.com>
Re: Experimental patch for inter-page delay in VACUUM
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 per process 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, Pennsylvania 19073

Mon, 10 Nov 2003 18:43:24 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Experimental patch for inter-page delay in VACUUM