RE: Raw vs Cooked space?

This still does not change the fact that from the benchmarking we have done we see less than a 3% difference on any job. To be honest, in many cases their was no difference as far as user response time, which is one of the most important factors for us. Good cache rates help any issues we might have with the speed of our i/o. I do not care if you get a 100% increase in i/o, if you seldom do i/o, the benefits seem low.(Sounds like I am starting a poem) I have no issues with the administration of raw space, I did it at my last work place.(more rhymes) From what I can tell, the operating system does a better job of handling remappable i/o errors than informix. If a disk error causes a chunk to go down, this causes both downtime as well as DBA time. Given that the number of times we have ended up doing restores of the database due to non-fatal disk errors has gone to 0 since going to cooked space, I tend to think the OS does do something different. I am open to finding out this is either pure coincidence, or due to other factors. If I find out there is no way the operating system does anything more as far as handling disk errors with a filesystem file than with managing raw space it would probably convince me that raw space would not hurt, but right now my impression is that for my company it would. Thanks for mentioning the context switching, that had not occured to me. Will >===== Original Message From acaldera@airmail.net ===== >The other factor that needs pointing out here is the benefits of using KAIO. KAIO runs on the actual >CPUVP's as opposed to the situation in cooked which utilizes AIOVP's which forces the CPUVP's to >yield the processor and do the 2nd most costly operation in UNIX: the context switch. This is >especially critical at checkpoint time as you are flushing buffers to disk and having to wait on the >AIOVP's to finish before the engine can unblock the server and allow transactions to proceed. Of >course, a badly designed raw dbspace configuration/saturated IO bus configuration can influence the >lack of performance improvement between raw and cooked. >Best advice to people who have trouble administering raw devices: draw a map and publish its >location. Device naming schemes where the symlinks are named according to usage status is also a >very good thing. > >HTH, >Alan > >William Rice wrote: > >> I keep hearing 25-35 percent improvement using raw space. >> I am assuming this is a 25 to 35 percent improvement on the i/o >> which is done. If you have a high cache rate, as well as good read >> ahead parameters I would suspect the difference in performance >> to be much less noticeable, except maybe in the case of checkpoint >> times. I suspect this to be the case because in our >> benchmarks of cooked vs. raw we found the difference >> in the length of time our processing took to be under 3%. >> Hope someone can clarify this for me. >> >> Will <SNIP> ------------------------------------------------------------ This e-mail has been sent to you courtesy of OperaMail, as a free service from Opera Software, makers of the award-winning Web Browser, Opera. Visit us at http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail account is waiting at: http://www.operamail.com/ ------------------------------------------------------------