On 25 Mar, Manfred Spraul wrote:
> Tom Lane wrote:
>
>>markw@osdl.org writes:
>>
>>
>>>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.
Mark