Erik Rijkers wrote:
Everything together: the raid is what Areca call 'raid10(1E)'.
(to be honest I don't remember what that 1E exactly means -
extra flexibility in the number of disks, I think).
Standard RAID10 only supports an even number of disks. The 1E variants
also allow putting an odd number in. If you're using an even number,
like in your case, the results are the same until you start losing
drives, at which point the degradation performance pattern changes a bit
due to differences in how things are striped. See these for more info:
http://bytepile.com/raid_class.php and
http://en.wikipedia.org/wiki/Non-standard_RAID_levels#IBM_ServeRAID_1E
http://publib.boulder.ibm.com/infocenter/eserver/v1r2/index.jsp?topic=/diricinfo/fqy0_craid1e.html
I don't think using RAID1E has anything to do with your results, but it
is possible given your test configuration that part of the difference
you're seeing relates to where on disk blocks are stored. If you take a
hard drive and write two copies of something onto it, the second copy
will be a little slower than the first. That's just because how drive
speed drops over the surface as you move further along it. There's some
examples of what that looks like at
http://projects.2ndquadrant.it/sites/default/files/pg-hw-bench-2010.pdf
on pages 21-23.
Returning to your higher level results, one of the variables you weren't
sure how to account for was caching effects on the standby--the
possibility that it just didn't have the data cached the same as the
master impacting results. The usual way I look for that is by graphing
the pgbench TPS over time. In that situation, you can see it shoot
upwards over time, very obvious pattern. Example at
http://projects.2ndquadrant.it/sites/default/files/pgbench-intro.pdf on
pages 36,37.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
g...@2ndquadrant.com www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
