Cook device vs Raw device

Currently our database data is stored in cooked chunks. Informix did state that using raw device is preferably but due to time contraints(other data was present which required repartitioning the drives) we decided to use cooked chunks. I am wondering, how much slower? Any parameters to set/change when using cooked chunks to improve the speed ? Thanks in advance !

Hi Matthew, When using cooked files you are basically stuck with the overhead of the OS. The overhead of the OS downgrades performance with Dynamic server mostly due to the fact that it needs to use the OS in order to store and retrieve data. This creates a problem if your OS experiences high volume. The reason is because like all OS the kernel needs to manage all the activity and associate it with the correct action to take... much like informix if you need to write to disk you are depending on the kernel to fork that process for you. In addition, Informix has no control in how the data is stored on disk (no contigous order) which is why raw disk devices are used instead. When using raw disks Informix can optimize its table access and can store rows of data in a way that Informix likes to do things. In addition, it bypasses overhead from your OS (KAIO) if your server supports this feature of disk I/O and can use direct data transfers from disk to memory and vice versa. In some cases such as Linux for example this feature of bypassing IO overhead does not matter. The informix server has a built in feature called Kernel Asynchronous Input Output (KAIO) which is basically your Informix virtual processor that spawns threads to and from disk (ie. if you need to write to disk or retrieve data). This is the feature that allows you to bypass your server OS disk overhead. Not all platforms have this feature.. most due. In this case however, using either raw disks or cooked files will not give you any performance advantage. You can set a few of the disk paramters in your onconfig file. Increase the number of page cleaners and AIO virtual processors (not KAIO) to help spawn more disk threads (make sure that these values are the same). This needs to be monitored so that you do not eat up to much resources for this feature. Informix is pretty good in using resources. I like to configure when using cooked files my AIO and page cleaners to the number of dbspaces I create. Theoretically, there is a thread for each dbspace that you have created. You cannot assign a vp to a particular dbspace but it (for me) is a good method in determining what to set for these parameteres. You can set these parameters using onmonitor or you can modify your onconfig parameters which is NUMAIOVPS and CLEANERS. Make sure that these parameters are identical to achieve optimum performance. I hope this explains it a little for you and helps you out. Lloyd AJ Wilson. Matthew Tan wrote in message <7rl4lu$3dg$1@violet.singnet.com.sg>... >Currently our database data is stored in cooked chunks. Informix did state >that using raw device is preferably but due to time contraints(other data >was present which required repartitioning the drives) we decided to use >cooked chunks. > >I am wondering, how much slower? Any parameters to set/change when using >cooked chunks to improve the speed ? > >Thanks in advance ! > >

Lloyd AJ Wilson wrote in message ... >Hi Matthew, > >When using cooked files you are basically stuck with the overhead of the OS. >The overhead of the OS downgrades performance with Dynamic server mostly due >to the fact that it needs to use the OS in order to store and retrieve data. >This creates a problem if your OS experiences high volume. The reason is >because like all OS the kernel needs to manage all the activity and >associate it with the correct action to take... much like informix if you >need to write to disk you are depending on the kernel to fork that process >for you. In addition, Informix has no control in how the data is stored on >disk (no contigous order) which is why raw disk devices are used instead. > >When using raw disks Informix can optimize its table access and can store >rows of data in a way that Informix likes to do things. In addition, it >bypasses overhead from your OS (KAIO) if your server supports this feature >of disk I/O and can use direct data transfers from disk to memory and vice >versa. > >In some cases such as Linux for example this feature of bypassing IO >overhead does not matter. The informix server has a built in feature called >Kernel Asynchronous Input Output (KAIO) which is basically your Informix Just to clarify that these threads work in conjunction with disk and memory. The threads send and retrieve data to and from memory without going throught the OS. I just wanted to clarify this point. >virtual processor that spawns threads to and from disk (ie. if you need to >write to disk or retrieve data). This is the feature that allows you to >bypass your server OS disk overhead. Not all platforms have this feature.. >most due. In this case however, using either raw disks or cooked files will >not give you any performance advantage. > >You can set a few of the disk paramters in your onconfig file. Increase the >number of page cleaners and AIO virtual processors (not KAIO) to help spawn >more disk threads (make sure that these values are the same). This needs to >be monitored so that you do not eat up to much resources for this feature. >Informix is pretty good in using resources. I like to configure when using >cooked files my AIO and page cleaners to the number of dbspaces I create. >Theoretically, there is a thread for each dbspace that you have created. >You cannot assign a vp to a particular dbspace but it (for me) is a good >method in determining what to set for these parameteres. You can set these >parameters using onmonitor or you can modify your onconfig parameters which >is NUMAIOVPS and CLEANERS. Make sure that these parameters are identical to >achieve optimum performance. > >I hope this explains it a little for you and helps you out. > >Lloyd AJ Wilson. > > >Matthew Tan wrote in message <7rl4lu$3dg$1@violet.singnet.com.sg>... >>Currently our database data is stored in cooked chunks. Informix did state >>that using raw device is preferably but due to time contraints(other data >>was present which required repartitioning the drives) we decided to use >>cooked chunks. >> >>I am wondering, how much slower? Any parameters to set/change when using >>cooked chunks to improve the speed ? >> >>Thanks in advance ! >> >> > >

Matthew Tan wrote: > > Currently our database data is stored in cooked chunks. Informix did state > that using raw device is preferably but due to time contraints(other data > was present which required repartitioning the drives) we decided to use > cooked chunks. > > I am wondering, how much slower? Any parameters to set/change when using > cooked chunks to improve the speed ? Nothing special you need to do. You can even bring the engine down, copy each cooked file to a separate RAW chunk at least as large, replace the cooked filename with a symbolic link to the RAW file and restart the engine. Performance is usually about 8-15% better with RAW chunks over COOKED devices and add another 7-10% for filesystem files. So expect 15-25% improvement. Art S. Kagel