On 7/17/2004 9:00 AM, Guthrie, Jeremy wrote:

> You could try turning it off. The PostgreSQL FSync option instructs PostgreSQL to call sync after every write operation.  Read the docs for the risks(there are some) but that should vastly improve your speed.
> 

The PostgreSQL development team (me included) strongly discourages from 
turning off fsync for production systems as this could possibly lead to 
serious data corruption.

Running with fsync turned on does not mean a sync after every write. It 
means that the system will issue an fsync() call on the WAL file on 
every transaction commit. For very busy databases, playing with 
commit_siblings and commit_wait can improve throughput. The global 
buffer flush and calling sync() is done only on checkpoints.


Jan

> 
> 
> From: Erik G. Burrows
> Sent: Fri 7/16/2004 11:02 PM
> To: Slony-I Mailing List
> Subject: RE: [Slony1-general] Performance
> 
> 
> Fsync is on, and I'm using a raid controller with an nv-ram backed
> buffer. iostat reports await times around 5ms at normal load.
> 
>> Are you running with fsync turned on?
>> 
>> ______________________________________________________________________
>> From: Erik G. Burrows
>> Sent: Fri 7/16/2004 8:40 PM
>> To: Slony-I Mailing List
>> Subject: [Slony1-general] Performance
>> 
>> 
>> I'm using PostgreSQL 7.4.3 and Slony-I 1.0.1 with Intel P4 and Xeon
>> machines.
>> 
>> I have a two-server replication setup, one database, one set, working
>> very well, but I have some questions about performance.
>> 
>> I'm not sure how to get some number like updates per second from
>> Slony-I, so to give you an idea of the activity of my system, I turned
>> on statement logging on the (otherwise idle) slave server. It's doing
>> about 600 statements/min.
>> 
>> My slon configuration is very standard, I haven't changed the 10 second
>> sync interval time, or any other option.
>> 
>> Since turning on replication, the CPU utilization of my master database
>> server has tripled, and doing some analysis on the log file (with
>> statement and duration logging turned on) I can see it's the "fetch 100
>> from LOG;" statements from Slony-I that are causing the increased load.
>> Each fetch takes 5 seconds to complete. At 10 second intervals, that's a
>> lot of cycles.
>> 
>> Doing frequent vacuum/vacuum full/analyze of the Slony-I tables has
>> little effect.
>> 
>> So, my question is: What can I do to reduce load on my master server
>> from Slony-I? 
>> 
>> Thanks,
>>   Erik G. Burrows
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


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