Обсуждение: Re: [pgsql-hackers-win32] fsync with sync, and Win32 unlink

> Consider either a box with many different postgresql instances, or one
> that run both postgresql and other software. Issuing sync() in that
> sitaution will cause sync of a lot of data that probably doesn't need
> syncing.
> But it'd probably be a very good thing on a dedicated server, giving the
> kernel the chance to optimise.

It is not like the sync is done every few seconds ! It is currently done
every 5 minutes (I actually think this is too frequent now that we have
bgwriter, 10 - 20 min would be sufficient). So imho even on a heavily
otherwise used system the sync will be better.

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:

> > Consider either a box with many different postgresql instances, or one
> > that run both postgresql and other software. Issuing sync() in that
> > sitaution will cause sync of a lot of data that probably doesn't need
> > syncing. 
> > But it'd probably be a very good thing on a dedicated server, giving the
> > kernel the chance to optimise.
> 
> It is not like the sync is done every few seconds ! It is currently done
> every 5 minutes (I actually think this is too frequent now that we have 
> bgwriter, 10 - 20 min would be sufficient). So imho even on a heavily 
> otherwise used system the sync will be better.

Well, the further apart it is the more dangerous it is to be calling sync...

I've seen some pretty severe damage caused by calling sync(2) on a loaded
system. The system in question was in the process of copying data to an NFS
mounted archival site. When the sync hit basically everything stopped until
the buffered network writes could be synced. The live database was basically
frozen for a few seconds and the web site nearly crashed. The sysadmin had to
send out a notice asking everybody to refrain from using sync until the
archival process had completed.

Now that's not a common situation, but I think it shows how doing things that
cause system-wide effects is unwise.


-- 
greg

Greg Stark <gsstark@mit.edu> writes:
> I've seen some pretty severe damage caused by calling sync(2) on a loaded
> system. The system in question was in the process of copying data to an NFS
> mounted archival site. When the sync hit basically everything stopped until
> the buffered network writes could be synced. The live database was basically
> frozen for a few seconds and the web site nearly crashed. The sysadmin had to
> send out a notice asking everybody to refrain from using sync until the
> archival process had completed.

This seems, um, hard to believe.  Did he shut down the standard syncer
daemon?  I have never seen a Unix system that would allow more than
thirty seconds' worth of unwritten buffers to accumulate, and would not
care to use one if it existed.
        regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

> This seems, um, hard to believe.  Did he shut down the standard syncer
> daemon?  I have never seen a Unix system that would allow more than
> thirty seconds' worth of unwritten buffers to accumulate, and would not
> care to use one if it existed.

Well it was Solaris so it didn't have the BSD 30s sync style strategy. But
this was a large NFS file transfer to another host on a 100Mb/s network. In
30s there could be a lot of writes buffered up. 

I'm not saying the behaviour was ideal, and I don't know exactly why it
interfered with anything else. But I'm not entirely surprised either.

-- 
greg