Re: raw v/s block I/O anomaly.....strange behaviour

In article <51a165$n6e@cnj.digex.net>, Atiqullah Hashmi <hashmi@cnj.digex.net> writes > >Hi, > >It's a related two-part prob. Pls help on whatever you can. > >(1) We have a strange situation. We are running an informix based >application which runs slow on one system(say 'B'ad) and fast on >another(say 'G'ood). We found that the database on G is on a >block device I/F of the disk(/dev/dsk/...), whereas B is using >char. I/F (/dev/rdsk/....) although you would expect performance >of raw interface to be faster. > >We found this situation on diff. environments e.g. > >a. Sol 2.5 on sun sparc1000 (using storage array) >b. Sol 2.4 on sun 670MP (using internal disks) >c. sunOS 4.1.3 on sun 670MP (using internal disks) >d. sol 2.4 on a sun sparc 20 (using internal disks) > >To compare timings on low level IO, we used dd comand as follows: >time dd if=<XX> of=/dev/null bs=2048 count=75000 >where XX was replaced with char. and block device path. bs=2048 >since informix uses 2k pages for I/O. We used diff. count values >and every time I/O using block I/F was faster. > >(2)Our Informix is using raw device. The path of informix database of B >was a link to the raw I/F. I changed the link to point to the char. >I/F of the same disk and the dd gave great timings. Although >strange, but looked like we found the answer why informix SQL >queries were running slower ie. solution was to use block I/F. > >However, after dd ran faster on block I/F, we expected informix sql >queries to run faster too. But that is not happening, in fact >they went a little worse. > >Any clues what is going on in 1 and/or 2 above ?. >If possible, pls reply directly. >Thanks much. >AH > With a block device the UNIX kernel does buffering and read ahead so it may be reading from <XX> whilst dd is writing to /dev/null. This won't happen with raw devices. Also even though dd is reading 2K amounts the kernel be reading in 16K chunks on the cooked chunk and so there is less overhead of communicating with the disk device driver i.e. fewer requests sent to the disk. Informix hoever does it's own buffering which is more intelligent than the UNIX kernels buffering. E.g. It knows to only read the next 2K on the disk since the rest of the data is not contiguous with the current position rather than reading in areas of disk which are never used in the query. -- David Williams