RE: Raw vs Cooked space?
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 >===== Original Message From <murray@quanta.co.nz> ===== >Paul > >1. I dont believe cooked is easier to backup. To backup using the OS you >need to switch the engine off-line which seems to defeat the purpose or is >inconvenient. Any attempt to backup with the engine on-line is likely to be >unrestorable. > >2. The increase of Raw over cooked has been discussed at length. Search the >Archives for Raw vs Cooked. The improvement depends upon you application, >hardware etc. Some recent measurement on certain hardware suggest around >25% - 35% improvement. > >Personally I would never consider cooked chunks in a live installation. I >find raw disk, away from prying eyes, far more convenient. > >Murray Wood > > >-----Original Message----- >From: owner-informix-list@iiug.org >[mailto:owner-informix-list@iiug.org]On Behalf Of Paul Jazwierski >Sent: Friday, January 28, 2000 6:10 AM >To: informix-list@iiug.org >Subject: Raw vs Cooked space? > > >Can anybody point me to any factual information about the >benefits/drawbacks of using raw vs cooked spaces. Cooked space is much >easier to do backups on, since I dont have to do an informix backup. It >seems to me that it is easier to use cooked space. I know that there are >speed benefits to using raw space, but what are the concrete numbers? Am >I going to get 100% performance improvement by using raw space? or is it >going to be 10%? I am trying to do a cost/benefit analysis on this but I >can't seem to find any information about it anywhere. > >Any info will be greatly appreciated. > >Paul Jazwierski, DBA ------------------------------------------------------------ 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/ ------------------------------------------------------------
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 > >===== Original Message From <murray@quanta.co.nz> ===== > >Paul > > > >1. I dont believe cooked is easier to backup. To backup using the OS you > >need to switch the engine off-line which seems to defeat the purpose or is > >inconvenient. Any attempt to backup with the engine on-line is likely to be > >unrestorable. > > > >2. The increase of Raw over cooked has been discussed at length. Search > the > >Archives for Raw vs Cooked. The improvement depends upon you application, > >hardware etc. Some recent measurement on certain hardware suggest around > >25% - 35% improvement. > > > >Personally I would never consider cooked chunks in a live installation. I > >find raw disk, away from prying eyes, far more convenient. > > > >Murray Wood > > > > > >-----Original Message----- > >From: owner-informix-list@iiug.org > >[mailto:owner-informix-list@iiug.org]On Behalf Of Paul Jazwierski > >Sent: Friday, January 28, 2000 6:10 AM > >To: informix-list@iiug.org > >Subject: Raw vs Cooked space? > > > > > >Can anybody point me to any factual information about the > >benefits/drawbacks of using raw vs cooked spaces. Cooked space is much > >easier to do backups on, since I dont have to do an informix backup. It > >seems to me that it is easier to use cooked space. I know that there are > >speed benefits to using raw space, but what are the concrete numbers? Am > >I going to get 100% performance improvement by using raw space? or is it > >going to be 10%? I am trying to do a cost/benefit analysis on this but I > >can't seem to find any information about it anywhere. > > > >Any info will be greatly appreciated. > > > >Paul Jazwierski, DBA > > ------------------------------------------------------------ > 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/ > ------------------------------------------------------------