Re: IDS 10 on RHEL4 Linux: I/O benchmark of RAW DEVICES vs BLOCK DEVICES vs COOKED FILES

Rupan3rd wrote: > Hello there, > > - The machine that have been used features 256Mb of cache on the disks > controller: how much do you think this influenced the results, especially in > giving advantage to the filesystem-based (COOKED) dbspace compared to the > low-level access (RAW / BLOCK) to the devices? > It gives more advantage to either test since they both go via the disk controller and so both use the cache. > - Given the same combination of OS and Informix version, are similar results > to be always and reasonably expected, independently from the underlying > hardware (with/without disk cache etc.)? > No. The results depend upon the hardware. Disk cache on/off will affect the results. > - Test #1 was clearly won by COOKED files configuration, but that test is not > representative of a typical OLTP kind of I/O: having an OLTP application that > needs to run on the machine, would you trust what Informix says in its > Admin Guide (see above) and results of #2 or go for COOKED files instead? > I would test further. The COOKED test should be as is. The RAW test should use minimal filesystem cache (say 500Mb) to cache things like the online.log. However it should use the reduction in fileysystem cache as buffers otherwise it is not a fair test. You need to use the same memory for caching in both tests. In the COOKED this should be fileysystem cache. In the RAW test this should be Informix buffers. Presumably somewhere there is a way to limit filesystem cache memory? In both tests set RESIDENT -1 in $ONCONFIG to avoid paging/swapping. Monitor to make sure no paging/swapping is occuring during the test. > - In which proven cases the sentence from Informix documentation "On UNIX, you > should use raw disk devices to store data whenever performance is important" > is to be taken in consideration? OLTP-style usage or what? > Anything since RAW I/O involves less CPU overhead. Make sure that the kernel limit on the maximum number of KAIO requests that can be done in parallel is set. aio-max-nr? Something like that in the release notes. Are there any KAIO errors in the online.log? In the release notes it says that KAIOON can be set to the maximum number of KAIO requests per CPU VP. We managed to hit >130,000 outstanding KAIO requests at any 1 time and started getting errors. However this was on RHEL3 where KAIO is NOT supported by IBM. We are yet to test on RHEL4. > - Any obvious reason why in test #2 only INSERT (not UPDATE nor DELETE) > operations were significantly slower when using COOKED files based dbspaces? Inserts are mainly writes only I guess. Updates/deletes have to locate the row hence do more reads since you are accessing different index/data pages each time? > > Hope my findings might be of some interest for someone. Yes. Please rebenchmark changing most of the filesystem cache to Informix buffers in the RAW case. I would leave say 500Mb for filesystem cache/kernel and the rest of the free memory for buffers. Set RESIDENT to -1 in both cases. And increase the RA_PAGES and RA_THRESHOLD in the raw case to allow Informix to do the same readahead as the filesystem would! Let us know the results (and the ONCONFIG that is used)... Also could you test on 10.00.FC5? > > Waiting for your feedback on my questions, > > Ciao, > Rupan3rd (from Italy)