Catering for slow(er) drive access

Here's an interesting scenario.... We are being pressured to move our Informix database engines (IDS 11.50.xC2) between datacenters from physical Solaris machines with direct-attached drives to non-global Solaris zones with SAN drives. All tests on the new hardware show that the SAN data access is about 30% slower than the old hardware. Politics are at play here which means I may be forced to accept this slower hardware solution. I'd like some ideas on how best to tune the Informix IDS engine for our OLAP instance to cater for the slower drive access; my initial thought is to increase buffer pools (memory & CPU seem slightly faster) and tune the read-ahead; however... RA_PAGES is currently 512 RA_THRESHOLD is currently 64 Do I:- Increase the threshold by 40% and leave RA_PAGES alone ? Decrease RA_PAGES ? Do both ? Increase RA_PAGES ? Any thoughts on this would be gratefully received...

U wrote: I'd like some ideas on how best to tune the Informix IDS engine for our OLAP instance to cater for the slower drive access; my initial thought is to increase buffer pools (memory & CPU seem slightly faster) and tune the read-ahead; however... RA_PAGES is currently 512 RA_THRESHOLD is currently 64 === If your not using light scans I would consider increasing buffers to minimize buffer turn over ratio (BTR). At any rate, if the read-ahead efficiency was good you might consider doubling the RA_PAGES/RA_THREASHOLD. Since this is a new hardware arrangement with slower IO(?) fewer IO request for bigger slugs of data might be more efficient. As always, us the OS tools to monitor IO and the onstat commands. If you using PDQ, you might experiment with those settings to improve preceived performance.

Actually I'm going to suggest that you reduce the RA_ parameters. The SAN is going to do lots of read ahead for you using its own cache. Under that the drives are doing read ahead also. So, you don't have to dedicate much or IDS's cache for read ahead freeing more buffers for pages that are actually being used. So, increase your cache as much as you can afford to, then reduce RA_ to: RA_PAGES 32 RA_THRESHOLD 8 Also make certain that the structures that you will be using for IDS chunks are NOT configured as RAID5! You should ONLY be using RAID10 for IDS chunks. Separate suggestion: suggest that you move the IDS servers onto small Intel/AMD multi-processor multi-core Linux boxes with lots of cheap hard attached disk. Your servers will run faster and more cheaply (mostly because you won't be sharing SAN storage with other applications and other machines) and you'll free up expensive SAN storage for other applications. Art Remember: NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! NO RAID5!!! Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jul 14, 2009 at 7:53 AM, Lello, Nick <Nick.Lello@nielsen.com> wrote: > Here's an interesting scenario.... > > We are being pressured to move our Informix database engines (IDS > 11.50.xC2) between datacenters from physical Solaris machines with > direct-attached drives to non-global Solaris zones with SAN drives. > > All tests on the new hardware show that the SAN data access is about 30% > slower than the old hardware. > > Politics are at play here which means I may be forced to accept this > slower hardware solution. > > I'd like some ideas on how best to tune the Informix IDS engine for our > OLAP instance to cater for the slower drive access; my initial thought > is to increase buffer pools (memory & CPU seem slightly faster) and tune > the read-ahead; however... > > RA_PAGES is currently 512 > > RA_THRESHOLD is currently 64> > Do I:- > > Increase the threshold by 40% and leave RA_PAGES alone ? > > Decrease RA_PAGES ? > > Do both ? > > Increase RA_PAGES ? > > Any thoughts on this would be gratefully received... > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5adfe1663af046eaaa9b2

Hi Nick, SAN drives slower than attached? Probably not optimally configured SAN. As Art already pointed, use RAID10. Stripe SAN arrays/volumes across all available physical disks, with large stripe/segment size (terminology probably differ from one SAN vendor to another). That's 512 KB in our case (can't go for more, we would if we could). If it was OLTP box I'd suggest 32 KB stripe/segment size on SAN. Logical volumes on SAN will be presented as physical disks to OS; don't stripe them, too much administrative overhead for probably no gain as it's already striped on SAN (may even hurt, haven't tested this setup). Create your volume groups, carve out logical volumes and use them as raw devices (with symbolic links, of course) for Informix chunks. Don't forget to follow up with the results :) HTH Davorin

SMALL Stripe sizes work better for IDS actually, 32 to 64K. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jul 14, 2009 at 10:48 AM, DAVORIN KREMENJAS < davorin.kremenjas@gmail.com> wrote: > Hi Nick, > > SAN drives slower than attached? > > Probably not optimally configured SAN. As Art already pointed, use RAID10. > Stripe SAN arrays/volumes across all available physical disks, with large > stripe/segment size (terminology probably differ from one SAN vendor to > another). That's 512 KB in our case (can't go for more, we would if we > could). > If it was OLTP box I'd suggest 32 KB stripe/segment size on SAN. > Logical volumes on SAN will be presented as physical disks to OS; don't > stripe > them, too much administrative overhead for probably no gain as it's already > striped on SAN (may even hurt, haven't tested this setup). > Create your volume groups, carve out logical volumes and use them as raw > devices (with symbolic links, of course) for Informix chunks. > > Don't forget to follow up with the results :) > > HTH > > Davorin > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5a72e267168046eabe881

Agreed for OLTP. On our "warehousing" instance we got even better performance going all the way to 512 KB, the largest segment size SAN would give us. Less IO requests per same amount of data. Cheers Davorin

Interesting. Makes sense. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jul 14, 2009 at 12:15 PM, DAVORIN KREMENJAS < davorin.kremenjas@gmail.com> wrote: > Agreed for OLTP. > > On our "warehousing" instance we got even better performance going all the > way > to 512 KB, the largest segment size SAN would give us. Less IO requests per > same amount of data. > > Cheers > > Davorin > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001636c5987954ff6b046ead8a20

Yup.... slower. It *is* a massively shared SAN fabric (attached hosts in the hundreds).... so far we have Sun & EMC working on why the drive performance isn't matching up to the current hardware; apparently I am the first person to notice a problem in this hardware environment (which also supports Oracle and Sybase ASE engines). I'm going to try for getting the stripes on our storage changed or at least identified... -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DAVORIN KREMENJAS Sent: 14 July 2009 15:49 To: ids@iiug.org Subject: Re: Catering for slow(er) drive access [16390] Hi Nick, SAN drives slower than attached? Probably not optimally configured SAN. As Art already pointed, use RAID10. Stripe SAN arrays/volumes across all available physical disks, with large stripe/segment size (terminology probably differ from one SAN vendor to another). That's 512 KB in our case (can't go for more, we would if we could). If it was OLTP box I'd suggest 32 KB stripe/segment size on SAN. Logical volumes on SAN will be presented as physical disks to OS; don't stripe them, too much administrative overhead for probably no gain as it's already striped on SAN (may even hurt, haven't tested this setup). Create your volume groups, carve out logical volumes and use them as raw devices (with symbolic links, of course) for Informix chunks. Don't forget to follow up with the results :) HTH Davorin ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.