Re: linux distro for better pg performance

Joseph Shraibman wrote:

> Is raid 5 much faster than raid 10? On a 4 disk array with 3 data disks
> and 1 parity disk, you have to write 4/3rds the original data, while on
> raid 10 you have to write 2 times the original data, so logically raid 5
> should be faster.

RAID 5 will give you more capacity, but is usually not recommended for
write intensive applications since RAID 5 writes require four I/O
operations: parity and data disks must be read, new data is compared to
data already on the drive and changes are noted, new parity is
calculated, both the parity and data disks are written to. Furthermore,
if a disk fails, performance is severely affected since all remaining
drives must be read for each I/O in order to recalculate the missing
disk drives data.

RAID 0+1 has the same performance and capacity as RAID 1+0 (10), but
less reliability since "a single drive failure will cause the whole
array to become, in essence, a RAID Level 0 array" so I don't know why
anyone would choose it over RAID 10 where multiple disks can fail.

RAID 1 has the same capacity as RAID 10 (n/2), but RAID 10 has better
performance so if you're going to have more than one drive pair, why not
go for RAID 10 and get the extra performance from striping?

I have been researching how to configure Postgres for a RAID 10 SAME
configuration as described in the Oracle paper "Optimal Storage
Configuration Made Easy"
(http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdf) Has
anyone delved into this before?

The filesystem choice is also a key element in database performance
tuning. In another Oracle paper entitled Tuning an "Oracle8i Database
Running Linux"
(http://otn.oracle.com/oramag/webcolumns/2002/techarticles/scalzo_linux02.html)
Dr. Bert Scalzo says, "The trouble with these tests-for example, Bonnie,
Bonnie++, Dbench, Iobench, Iozone, Mongo, and Postmark-is that they are
basic file system throughput tests, so their results generally do not
pertain in any meaningful fashion to the way relational database systems
access data files." Instead he suggests users benchmarking filesystems
for database applications should use these two well-known and widely
accepted database benchmarks:

AS3AP (http://www.benchmarkresources.com/handbook/5.html) a scalable,
portable ANSI SQL relational database benchmark that provides a
comprehensive set of tests of database-processing power; has built-in
scalability and portability for testing a broad range of systems;
minimizes human effort in implementing and running benchmark tests; and
provides a uniform, metric, straightforward interpretation of the results.

TPC-C (http://www.tpc.org/) an online transaction processing (OLTP)
benchmark that involves a mix of five concurrent transactions of various
types and either executes completely online or queries for deferred
execution. The database comprises nine types of tables, having a wide
range of record and population sizes. This benchmark measures the number
of transactions per second.

I encourage you to read the paper -- Dr. Scalzo's results will surprise
you; however, while he benchmarked ext2, ext3, ReiserFS, JFS, and RAW,
he did not include XFS.

SGI and IBM did a more detailed study on Linux filesystem performance,
which included XFS, ext2, ext3 (various modes), ReiserFS, and JRS, and
the results are presented in a paper entitled "Filesystem Performance
and Scalability in Linux 2.4.17"
(http://oss.sgi.com/projects/xfs/papers/filesystem-perf-tm.pdf) This
paper goes over the details on how to properly conduct a filesystem
benchmark and addresses scaling and load more so than Dr. Scalzo's tests.

For further study, I have compiled a list of Linux filesystem resources
at: http://jamesthornton.com/hotlist/linux-filesystems/.
--

James Thornton
______________________________________________________
Internet Business Consultant, http://jamesthornton.com