Erik Rijkers wrote:
> OS: Centos 5.4
> 2 quadcores: Intel(R) Xeon(R) CPU X5482 @ 3.20GHz
> Areca 1280ML
> primary and standby db both on a 12 disk array (sata 7200rpm, Seagat Barracuda ES.2)
>
To fill in from data you already mentioned upthread:
32 GB RAM
CentOS release 5.4 (Final), x86_64 Linux, 2.6.18-164.el5
Thanks for the all the reporting you've done here, really helpful.
Questions to make sure I'm trying to duplicate the right thing here:
Is your disk array all configured as one big RAID10 volume, so
essentially a 6-disk stripe with redundancy, or something else? In
particular I want know whether the WAL/database/archives are split onto
separate volumes or all on one big one when you were testing.
Is this is on ext3 with standard mount parameters?
Also, can you confirm that every test you ran only had a single pgbench
worker thread (-j 1 or not specified)? That looked to be the case from
the ones I saw where you posted the whole command used. It would not
surprise me to find that the CPU usage profile of a standby is just
different enough from the primary that it results in the pgbench program
not being scheduled enough time, due to the known Linux issues in that
area. Not going to assume that, of course, just one thing I want to
check when trying to replicate what you've run into.
I didn't see any glaring HS performance issues like you've been
reporting on last time I tried performance testing in this area, just a
small percentage drop. But I didn't specifically go looking for it
either. With your testing rig out of service, we're going to try and
replicate that on a system here. My home server is like a scaled down
version of yours (single quad-core, 8GB RAM, smaller Areca controller, 5
disks instead of 12) and it's running the same CentOS version. If the
problems really universal I should see it here too.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us