On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
>>>I could certainly do some testing if you want to see how DBT-2 does.
>>>Just tell me what to do. ;)
>>Just do some runs that are identical except for the wal_sync_method
>>setting.  Note that this should not have any impact on SELECT
>>performance, only insert/update/delete performance.
> I've made a test run that compares fsync and fdatasync: The performance 
> was identical:
> - with fdatasync:
> http://khack.osdl.org/stp/290607/
> - with fsync:
> http://khack.osdl.org/stp/290483/
> I don't understand why. Mark - is there a battery backed write cache in 
> the raid controller, or something similar that might skew the results? 
> The test generates quite a lot of wal traffic - around 1.5 MB/sec. 
> Perhaps the writes are so large that the added overhead of syncing the 
> inode is not noticable?
> Is the pg_xlog directory on a seperate drive?
> Btw, it's possible to request such tests through the web-interface, see
> http://www.osdl.org/lab_activities/kernel_testing/stp/script_param.html

We have 2 Adaptec 2200s controllers, without the battery backed add-on,
connected to four 10-disk arrays in those systems.  I can't think of
anything off hand that would skew the results.

The pg_xlog directory is not on a separate drive.  I haven't found the
best way to lay out of the drives on those systems yet, so I just have
everything on a 28 drive lvm2 volume.


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to