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
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly