Disk Layout

Posted in 1999

Steve Romankiw — Thu, 10 Jun 1999 13:57:55 -0400 — source: Informix-list mailing list archive (1991-1998)

--------------410F35DE69FD1DC3FE027159 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I thought I would start a thread to talk about advantages/disadvantages of disk layout approaches. Given the following, how would you approach. * 10-9.2GB drives (20 drives with RAID) * RAID 0+1 * OLTP Environment * 500+ Users * One instance, one database (50GB w/ 500+ tables) * 8 dbspaces (2 for idx and 6 for data) * 4 tmp spaces * 6-cpu server with 2GB RAM Let me start off the discussion: Large Stripes Set vs. Small Stipes Sets vs. No stripe set --------------------------------------------------------------------------- LSS - Treat all disks as JBOD. Create stripe sets across all disks, i.e., each stripe set has ten members. Create chunks to hold critical spaces and dbspaces. All dbspaces would be spread out across all the disks. I/O would benefit from disk parallelism. Critical dbspaces, data/index, and temp spaces "might" be located on the same disks. IFMX fragmentation would not be maximized because all data is located on same disks. SSS - Create striped raid sets of (3, 4, ...?) disks. This approach would allow you to separate dbspaces across various raid sets. Critical spaces could be placed on separate raid sets. This approach would allow you to maximize IFMX fragmentation. Continue to benefit from I/O parallelism. NSS - Create simple raid set. Define roughly 4-2gb chunks on a single disk. The benefit of this is you know "where" your data is. You don't benefit from I/O parallelism. Managing TMP spaces -------------------------------- Should you mirror your temp spaces? If a tmp space is down, informix should ignore and use the remaining tmp spaces. If tmp spaces are generally "sequential" dbspaces, is there much benefit in striping the underlying disks? Table placement on disk -------------------------------- Generally, the highly accessed tables are placed in the middle drives to get the best possible performance. Has disk technology advanced enough whereas the inner-middle-outer does not matter for table placement. Interested others opinions/approaches... Steve Romankiw --------------410F35DE69FD1DC3FE027159 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt>I thought I would start a thread to talk about advantages/disadvantages of disk layout approaches.</tt><tt></tt> <tt>Given the following, how would you approach.</tt><tt></tt> <tt>*    10-9.2GB drives (20 drives with RAID)</tt> <tt>*    RAID 0+1</tt> <tt>*    OLTP Environment</tt> <tt>*    500+ Users</tt> <tt>*    One instance, one database (50GB w/ 500+ tables)</tt> <tt>*    8 dbspaces (2 for idx and 6 for data)</tt> <tt>*    4 tmp spaces</tt> <tt>*    6-cpu server with 2GB RAM</tt><tt></tt> <tt>Let me start off the discussion:</tt><tt></tt> <tt>Large Stripes Set vs. Small Stipes Sets vs. No stripe set</tt> <tt>---------------------------------------------------------------------------</tt> <tt>LSS - Treat all disks as JBOD.  Create stripe sets across all disks, i.e., each stripe set has ten members.  Create chunks to hold critical spaces and dbspaces.  All dbspaces would be spread out across all the disks.  I/O would benefit from disk parallelism.  Critical dbspaces, data/index, and temp spaces "might" be located on the same disks.  IFMX fragmentation would not be maximized because all data is located on same disks.</tt><tt></tt> <tt>SSS - Create striped raid sets of (3, 4, ...?) disks.  This approach would allow you to separate dbspaces across various raid sets.  Critical spaces could be placed on separate raid sets.  This approach would allow you to maximize IFMX fragmentation.  Continue to benefit from I/O parallelism.</tt><tt></tt> <tt>NSS - Create simple raid set.  Define roughly 4-2gb chunks on a single disk.  The benefit of this is you know "where" your data is.  You don't benefit from I/O parallelism.</tt><tt></tt> <tt>Managing TMP spaces</tt> <tt>--------------------------------</tt> <tt>Should you mirror your temp spaces?  If a tmp space is down, informix should ignore and use the remaining tmp spaces.</tt> <tt>If tmp spaces are generally "sequential" dbspaces, is there much benefit in striping the underlying disks?</tt><tt></tt> <tt>Table placement on disk</tt> -------------------------------- <tt>Generally, the highly accessed tables are placed in the middle drives to get the best possible performance.  Has disk technology advanced enough whereas the inner-middle-outer does not matter for table placement.</tt> <tt></tt> <tt></tt> <tt>Interested others opinions/approaches...</tt><tt></tt> <tt>Steve Romankiw</tt></html> --------------410F35DE69FD1DC3FE027159--