Raw Disk still preferred for 11.5?
Question: for a new IDS 11.5 setup on SLES 10 with SDS, are raw devices still the best choice for chunks? No single verdict, but a consensus emerged: on Linux, raw devices are largely deprecated and enabling DIRECT_IO with cooked files gives nearly the same performance with less administrative effort; on other platforms (e.g. AIX with DIO/CIO) investigate first and use raw if in doubt. Others argued for raw anyway, since it prevents admins or filesystem cleanups from deleting chunk files, while cooked files ease OS-level backup and benefit from OS buffering. Advice was to benchmark both.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
I am setting up a new set of servers that will utilize the SDS capabiltiy of IDS 11.5 and just want to make sure that raw disk space is still the best way to go. I plan to have at least 3 SDS servers. SLES 10.2 4 processors per server 32 GB ram per server Thanks in advance for your comments. Laurie Laurie Gustin IT Programmer Analyst Department of Public Safety lgustin@utah.gov 801-965-4410
If you are on a SAN, raw disk is really not necessary, it may yield a small performance gain, but it may also create extra work for you. If performance is critical you might want to do raw disks, but I have been seeing and hearing only around 10% improvement. I'd actually recommend against raw disks unless you are doing some kind of major transactions that the extra work to used them gives you the small amount of extra speed. The other advantage to using cooked files is the ease of doing backups. If you use raw disks you will be at the mercy of the database engine to do backups. If you stay with cooked files you can simply copy partition files after shutting down the engine. Again this depends a lot on your needs and availability. Remember, your database is as fast as your hard drives, so if you have 15K drives vs 10K drives, you have significant speed differences. What speed are your drives? Laurie Gustin wrote: > I am setting up a new set of servers that will utilize the SDS > capabiltiy of IDS 11.5 and just want to make sure that raw disk space is > still the best way to go. > > I plan to have at least 3 SDS servers. > > SLES 10.2 > 4 processors per server > 32 GB ram per server > > Thanks in advance for your comments. > > Laurie > > Laurie Gustin > IT Programmer Analyst > Department of Public Safety > lgustin@utah.gov <mailto:lgustin@utah.gov> > 801-965-4410
"InDeep" <indeep@indeep.com> wrote in message news:48ea5464$0$5171$6c36adad@news.usenetserver.com... > If you are on a SAN, raw disk is really not necessary, it may yield a > small performance gain, Hmmm. I though most of the perceived gain in performance waas supposed to come from bypassing the operating system's I/O operations. In which case, why would it make any difference what the underlying storage system is? To address the original question, I have it in mind that the orthodoxy these days was that the File System cacheing that was thought to slow down cooked speeds was now avoidable in modern versions of Linux (such as the one you propose) anyway and there was little difference betweeen one and the other. Usually I read things like " ...I have been seeing and hearing only around 10% improvement [therefore] I'd actually recommend against raw disks" but never really understand them, as even if there was minimal performance benefit I'd still probably keep things raw because: a. There's less likeliehood that someone will try to access the files directly and b. It makes things a little more arcane and therefore makes it slightly more difficult to take the support away from me (especially now Informix is like DB2 and completely autonomic and so doesn't need any administration ;-)) Fernando Nunes seems to know what he's talking about: http://informix-technology.blogspot.com/2007/05/cheetah-spot-by-spot-directio.html
Neil Truby wrote: > "InDeep" <indeep@indeep.com> wrote in message > news:48ea5464$0$5171$6c36adad@news.usenetserver.com... >> If you are on a SAN, raw disk is really not necessary, it may yield a >> small performance gain, > > Hmmm. I though most of the perceived gain in performance waas supposed > to come from bypassing the operating system's I/O operations. In which > case, why would it make any difference what the underlying storage > system is? > > To address the original question, I have it in mind that the orthodoxy > these days was that the File System cacheing that was thought to slow > down cooked speeds was now avoidable in modern versions of Linux (such > as the one you propose) anyway and there was little difference betweeen > one and the other. > > Usually I read things like " ...I have been seeing and hearing only > around 10% improvement [therefore] I'd actually recommend against raw > disks" but never really understand them, as even if there was minimal > performance benefit I'd still probably keep things raw because: > a. There's less likeliehood that someone will try to access the files > directly and > b. It makes things a little more arcane and therefore makes it slightly > more difficult to take the support away from me (especially now Informix > is like DB2 and completely autonomic and so doesn't need any > administration ;-)) > > Fernando Nunes seems to know what he's talking about: > http://informix-technology.blogspot.com/2007/05/cheetah-spot-by-spot-directio.html > > > Thanks for the reference. In Linux I would not use raw devices. I have the impression that they're more or less deprecated, and DIRECT_IO should work very well on Linux since IDS used it there first AFAIK. But after writing that article I've done a bit of investigation, and this seems to be a very complex issue in other OS... I'd like to see some clarification from R&D... On AIX you have DIO and CIO... From some IBM AIX publications, the first without the later is not very efficient. And CIO has a lot about it... So, I would say: On Linux, use DIRECT_IO. On other systems do a real deep investigation. In case of doubts use RAW. If you don't want the extra job then just use DIRECT_IO... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...
Hello Laurie, Everyone here is right. I would like to add that, if you have time, TEST BOTH. Some operating systems and hardware run better on RAW. I'm guessing that yours will, too. Plus if you currently use RAW, then that will be what you are most comfortable with and skilled at. Ironically, I use cooked files with hardware mirroring (on RAID 10). That gives me the advantages of remappable I/O and O.S. buffering. In other words, if there is a bad spot on the disk, it automatically gets marked as bad and then gets a good copy of that spot from the hardware mirror. All my dbspaces (which are not mirrored in Informix) stay up and I never even know that there was a problem. As to the "O.S. buffering", both Informix and the operating system hold data (from cooked files) in memory so that the CPU does not have to get the same information from the disk. This can give a hidden boost in speed when Informix can't find the data in the BUFFERS but instead (and I am oversimplifying here) finds it in the operating system buffers. The AIX flavor of Unix is well suited for this. I have read that, in the past, other flavors of Unix were not. For me AIX RAW and cooked ran at about the same speed. Again, in your case I recommend RAW for the reasons I mentioned at the beginning. L.S.
I would make a strong case for using RAW disks on any system --- which is simply it stops system admins screwing up your database. I learnt this the painful way on a system running with cooked chunks -- a new system admin saw the filesystem was filling up and removed what he perceived as being 'junk' (one of my chunks) --- Informix merrily continued running for another month unti the machine was rebooted and then -- voila! One ruined database because the chunk disappeared as soon as the engine closed down. Of course, if you have sole control of the system hosting the engine this won't be an issue. -----Original Message----- From: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] On Behalf Of Fernando Nunes Sent: 06 October 2008 22:42 To: informix-list@iiug.org Subject: Re: Raw Disk still preferred for 11.5? Neil Truby wrote: > "InDeep" <indeep@indeep.com> wrote in message > news:48ea5464$0$5171$6c36adad@news.usenetserver.com... >> If you are on a SAN, raw disk is really not necessary, it may yield a >> small performance gain, > > Hmmm. I though most of the perceived gain in performance waas supposed > to come from bypassing the operating system's I/O operations. In which > case, why would it make any difference what the underlying storage > system is? > > To address the original question, I have it in mind that the orthodoxy > these days was that the File System cacheing that was thought to slow > down cooked speeds was now avoidable in modern versions of Linux (such > as the one you propose) anyway and there was little difference betweeen > one and the other. > > Usually I read things like " ...I have been seeing and hearing only > around 10% improvement [therefore] I'd actually recommend against raw > disks" but never really understand them, as even if there was minimal > performance benefit I'd still probably keep things raw because: > a. There's less likeliehood that someone will try to access the files > directly and > b. It makes things a little more arcane and therefore makes it slightly > more difficult to take the support away from me (especially now Informix > is like DB2 and completely autonomic and so doesn't need any > administration ;-)) > > Fernando Nunes seems to know what he's talking about: > http://informix-technology.blogspot.com/2007/05/cheetah-spot-by-spot-dir ectio.html > > > Thanks for the reference. In Linux I would not use raw devices. I have the impression that they're more or less deprecated, and DIRECT_IO should work very well on Linux since IDS used it there first AFAIK. But after writing that article I've done a bit of investigation, and this seems to be a very complex issue in other OS... I'd like to see some clarification from R&D... On AIX you have DIO and CIO... From some IBM AIX publications, the first without the later is not very efficient. And CIO has a lot about it... So, I would say: On Linux, use DIRECT_IO. On other systems do a real deep investigation. In case of doubts use RAW. If you don't want the extra job then just use DIRECT_IO... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list
Fernando, Great article you put out. Yet another great Informix feature, DIRECT_IO. I would not have read about this other than your article. I'd still steer clear of raw disks unless they were somehow proven to add value, otherwise, I find them somewhat extra work. I guess I'm admitting I'm lazy, and DBA work is not the only thing I want to do. I'd rather work with cooked simply because it accommodates my laziness. *<8o) If you are on raw disks, remember, unless you are on a SAN that can provide san-level replication and san-level recovery of lost data, you will be limited to Informix utilities to restore data. This is something I'm not sure I'd want to limit myself to unless raw is something that is a proven value-add, and something you just can't live without. I still think cooked is fine for 99% of the situations out there on Linux--but hey I could be wrong. Keep up the great articles, good work! Fernando Nunes wrote: > Neil Truby wrote: >> "InDeep" <indeep@indeep.com> wrote in message >> news:48ea5464$0$5171$6c36adad@news.usenetserver.com... >>> If you are on a SAN, raw disk is really not necessary, it may yield a >>> small performance gain, >> >> Hmmm. I though most of the perceived gain in performance waas >> supposed to come from bypassing the operating system's I/O >> operations. In which case, why would it make any difference what the >> underlying storage system is? >> >> To address the original question, I have it in mind that the orthodoxy >> these days was that the File System cacheing that was thought to slow >> down cooked speeds was now avoidable in modern versions of Linux (such >> as the one you propose) anyway and there was little difference >> betweeen one and the other. >> >> Usually I read things like " ...I have been seeing and hearing only >> around 10% improvement [therefore] I'd actually recommend against raw >> disks" but never really understand them, as even if there was minimal >> performance benefit I'd still probably keep things raw because: >> a. There's less likeliehood that someone will try to access the files >> directly and >> b. It makes things a little more arcane and therefore makes it >> slightly more difficult to take the support away from me (especially >> now Informix is like DB2 and completely autonomic and so doesn't need >> any administration ;-)) >> >> Fernando Nunes seems to know what he's talking about: >> http://informix-technology.blogspot.com/2007/05/cheetah-spot-by-spot-directio.html >> >> >> > > Thanks for the reference. In Linux I would not use raw devices. I have > the impression that they're more or less deprecated, and DIRECT_IO > should work very well on Linux since IDS used it there first AFAIK. > But after writing that article I've done a bit of investigation, and > this seems to be a very complex issue in other OS... I'd like to see > some clarification from R&D... On AIX you have DIO and CIO... From some > IBM AIX publications, the first without the later is not very efficient. > And CIO has a lot about it... > > So, I would say: On Linux, use DIRECT_IO. On other systems do a real > deep investigation. In case of doubts use RAW. If you don't want the > extra job then just use DIRECT_IO... > > Regards. >
InDeep wrote: > Fernando, > > Great article you put out. Yet another great Informix > feature, DIRECT_IO. I would not have read about this other > than your article. > Because you don't read the release notes? > but hey I could be wrong. > Well, there's a novel concept. :op -- Cheers, Obnoxio the Clown http://obotheclown.blogspot.com
Obnoxio The Clown wrote: > InDeep wrote: >> Fernando, >> >> Great article you put out. Yet another great Informix feature, >> DIRECT_IO. I would not have read about this other than your article. >> > > Because you don't read the release notes? >> but hey I could be wrong. >> > > Well, there's a novel concept. :op > harsh but fair. *<8o)