Re: IDS i/o and Solaris
"Neil Truby" <neil.truby@ardenta.com> wrote in message news:6ned3cFl4briU1@mid.individual.net... > "Frank Langelage" <frank@lafr.de> wrote in message > news:6nec2lFlcrnuU1@mid.individual.net... >> Neil Truby wrote: >>> IDS 10.0FC8W2 on Solaris 10. >>> >>> We're just migrating to a new server from IDS 10.0FC8W2 on Solaris 9. >>> >>> The customer's SysAdmin has seen great results on Oracle using Solaris >>> 10 Direct i/o onto file system containers (ie cooked files), and really >>> wants to try same on the Informix database. >>> >>> Any reason not to give it a try? >> >> Not having dedicated filesystems for the informix datafiles would be a >> reason against that. >> Direct IO is a mount option for the whole filesystem, so all I/O to files >> on this filesystem bypass the buffer chache of the OS. >> No problem for the informix data as there is the cache of IDS, but other >> file IO will suffer. >> But why not use raw devices? >> From our experience this will give the best performance. > > The whole fs would be dedicated to /opt/informix, which would be chunks > plus binaries only. I restored a 40-odd Gig database. To the direct I/O file system chunks it took 24 mins the first time, 23 mins the second. Restoring to raw devices it took 19 mins the first time, 20 the second. Of course, a restore is (hopefully) a one-off exercise, albeit very I/O intensive. How much should I read into these results evidence of raw's likely superioroty in general OLTP operations?
> From: neil.truby@ardenta.com > I restored a 40-odd Gig database. > To the direct I/O file system chunks it took 24 mins the first time, 23 mins > the second. > Restoring to raw devices it took 19 mins the first time, 20 the second. > > Of course, a restore is (hopefully) a one-off exercise, albeit very I/O > intensive. How much should I read into these results evidence of raw's > likely superioroty in general OLTP operations? > It depends. :-) If you have a mission critical high volume OLTP system that is I/O bound, then you'd probably want raw. We're talking about a 10% difference or so. You have to weigh that against the ease of maintenance of using the cooked chunks. Assuming that your OLTP databases are not too huge. (I wonder if OTC had written a blog about purging the OLTP system of old/outdated data...) If the need for speed outweighs the costs of additional setup, maintenance, etc ... then go with the raw disk. Otherwise, go with whatever is easier for you to setup and maintain. (Meaning that if you think its easier to setup and maintain raw, then go raw.) The real question is how fast is fast enough? Using your example, if we were to extrapolate for a larger system. Lets say 400 gig, then the 10% time difference might mean something so then raw makes more sense. HTH -G _________________________________________________________________ Get 5 GB of storage with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_112008
"Ian Michael Gumby" <im_gumby@hotmail.com> wrote in message news:mailman.305.1226280848.874.informix-list@iiug.org... > From: neil.truby@ardenta.com > I restored a 40-odd Gig database. > To the direct I/O file system chunks it took 24 mins the first time, 23 > mins > the second. > Restoring to raw devices it took 19 mins the first time, 20 the second. > > Of course, a restore is (hopefully) a one-off exercise, albeit very I/O > intensive. How much should I read into these results evidence of raw's > likely superioroty in general OLTP operations? > >> It depends. :-) If you have a mission critical high volume OLTP system that is I/O bound, then you'd probably want raw. We're talking about a 10% difference or so. You have to weigh that against the ease of maintenance of using the cooked chunks. Assuming that your OLTP databases are not too huge. (I wonder if OTC had written a blog about purging the OLTP system of old/outdated data...) If the need for speed outweighs the costs of additional setup, maintenance, etc ... then go with the raw disk. Otherwise, go with whatever is easier for you to setup and maintain. (Meaning that if you think its easier to setup and maintain raw, then go raw.) The real question is how fast is fast enough? >> Using your example, if we were to extrapolate for a larger system. Lets >> say 400 gig, then the 10% time difference might mean something so then >> raw makes more sense. Thanks. A couple of points on what you say: The OLTP database is about 70g in size. The set-up is a one-off cost, which I've already incurred to do the test, but otherwise a fair point. I don't buy this argument that cooked files are necessaily easier to manage. I guess you can look at them with a simple ls, and measure their sizes with df, but is the management of raw otherwise that difficult? (To argue against myself for a minute, the answer is probably "yes" in Solaris, where the OS-supplied logical volume manager and in particular its soft partition functionality is very poor indeed from a reporting and space tracking point of view!). On your last point ("Lets say 400 gig, then the 10% time difference might mean something so then raw makes more sense") I assume you're talking abou the restore time itself? One thing I didn't mention is that in the cooked file restore there's an additional overhead of 30 minutes odd whilst Informix initialises the chunks.