Re: Informix OnLine and Striping

Will Hartung - Master Rallyeist (villy@uunet.uu.net) wrote: [preliminary stuff deleted ] : When we looked at the striping, we looked at it this way: : If we break the performance game down into it's atomic pieces, the : disk is the slowest piece. Algortithms etc are important as well, : but they are typically slow because they move to much data, which : inevitably comes from the disk drives. So, to increase performance of : the system we can increase the performance of the disk, or we can : reduce the accesses to the disk. : One way to reduce disk access is by reducing the volume of data : being read off of the disk. This can be done by both removing data : and by making sure the optimiser is processing our queries : appropiately. : Another way is by cacheing more of the data in memory, but that : doesn't help much when the process calls for scanning a million : rows. Queries like that can just flush your caches down the tubes. : Anything that would be worth keeping around ends up getting : washed away as the cache keeps up with the table scan. It would be : nice if there was some sort of limit as to how much of the cache a : massive table scan can obiliterate. I'm not sure what you're getting at here, Will. Massive table scans should only hit the Big Buffers, so you should only get eight buffers (per table scan) flushed "down the tubes". That seems a very reasonable limit to me! If you are seeing the behaviour you describe, then that sounds like some weird kind of bug! : If we have reduced to a minimum the amount of data we need to move : to/from the disks, then the next step is to speed up the disks : themselves. Since applying more voltage to the disk motors doesn't : seem to work, and their aren't any options for adding more wires : to the SCSI bus to make it wider, and we assume that the computer : can feed the disks as fast as they can take the data (i.e. most of : the time the computer is waiting on the disk drives, and not the : other way around), we need to have more drives to handle the load. : When the crowds come in at lunch, the bank adds more tellers. : Striping helps achieve that, I think, because it can help widen : the path that the data travels. [lots more stuff about benefits of striping deleted] : So, in summary, I think that the striping gives a benefit, but I'd : like to hear some more anti-stripe comments etc. Just because it : worked doesn't mean that it was the best approach. : I think in the new system, having the page cleaners hitting two : volumes (striped) with the heaviest tables on them, specifically : tables that are often joined together, should help leverage off of the : extra CPUs in the system. If I can route them through seperate : controllers, than even better, but we'll see. But I'd like comments on : that approach as well. : Sorry for the length, : Will : (villy@collinscomp.com) In my h/w environment I guess I have a very different outlook. I would never consider *NOT* striping, unless I was absolutely convinced that I was going to hit some other bottleneck before i/o. Typically I like to have each chunk on a raw device striped over four to eight spindles. Preferably, I would like to have each spindle on a separate SCSI channel, but even on our systems, that is a luxury I cannot always afford. Logical Log I try to put on a separate, unstriped, preferably dedicated spindle, but I have seen good results from putting it in with my stripes, when I have not been able to supply a single, low activity spindle. In this scenario the main i/o issue historically has been the inability to separate index from data, as one has been able to do for years with Oracle and Ingres (and Sybase???). Also, our systems are perhaps unusual in that I never configure more than one page cleaner, relying on the opsys' Async I/O to write simultaneously to all my disks. graeme -- Disclaimer: The author's opinions are his own, and not necessarily those of Pyramid Technology Ltd. or Pyramid Technology Inc. --------------------------------------------------------------------------- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk --------------------------------------------------------------------------- We have the technology. The tricky bit is learning how to use it.