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