On Thu, 28 Jun 2001, Lamar Owen wrote:
> On Thursday 28 June 2001 15:33, Steve Wolfe wrote:
> > > Hrmm, well, we're running it with fsync disabled, and according to the
> > > docs, that should make the WAL_SYNC_METHOD irrelevant. We had
> > > unacceptable performance with fsync enabled.
>
> > I'm not as familiar with Solaris as I am with Linux, but I do recall
> > seeing benchmarks that show a significant speed increase in many
> > applications (as much as 40%) by using the "best" compiler optimization
> > flags - you may want to look at what it's being compiled with on your
> > machine.
>
> While on this subject, I just reinstalled one of our devel servers with a
> fresh RHL 7.1 setup, with software RAID 1 enabled (easy to do with the RHL
> graphical installer, FWIW). While I could have just modified the existing
> setup to use RAID, I wanted to dink with the partitioning as well -- which is
> easiest in a reinstall situation.
>
> RAID 1 doesn't change the PostgreSQL performance on the regression tests
> significantly. This machine, on multiple runs of 'time ./pg_regress
> --schedule=parallel_schedule' on the same UDMA66 drives without RAID 1 posted
> an average 'real' number of 44 seconds. With RAID 1 (and the same drives,
> controllers, OS, etc) posts an average of 42 seconds -- not statistically
> significant. Yes, $PGDATA was on a RAID device... :-).
>
> So, while PostgreSQL will benefit from the redundancy of the RAID, it neither
> suffers significantly from the write overhead, nor does it seem to greatly
> benefit from the increased read bandwidth, at least in the limited
> performance testing afforded by the regression tests (which have been used
> for some time as a crude benchmark).
Unless you are using Neil Brown's patches, you do not have increased read
bandwidth. (Unless they were integrated into latest kernels).
You can test it by doing time dd if=/dev/mdxx bs=64k size=(a lot) and
compare it versus dd'ing from underlying device.
