iostat bug 4961

hopehope123 I am not sure it is impossible. I have four 10,000rpm Ultra-320 SCSI hard drives (and two 7,200 rpm EIDE hard drives on the same channel) on my machine. If I had eight, and stuck four on each SCSI controller, I imagine I might get it up there if the kernel and the applications could keep up with it. If I spun off 8 processes copying hard drives todev-null, it might work. I have two hyperthreaded 3.06 Xeon processors with 1 MByte L3 caches, so they can probably keep up with the interrupt load.

Does vmstat tell you the same thing? It is unlikely that both are in error unless the kernel is reporting incorrectly.

As a practical matter, I seldom see over 50 Megabytes-second transfers with the disk drives, but I see that fairly often.

$ uname -a Linux trillian 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU-Linux They are up to Update 6 as of about a week ago.

$ catetc-redhat-release Red Hat Enterprise Linux ES release 3 (Taroon Update 6)

How does Oracle run the hard drives? I use IBM DB2, and it runs them raw, so it can do IO in 65536-byte blocks to contiguous hard drive space. It bypbuttes the Linux file system entirely, but used the device drivers of course. If Oracle uses the regular ext2, or worse ext3, file systems, there is a noticeable increase in overhead. In fact, I can measure the slowdown when switching from ext2 to ext3 file systems if I run DB2 that way (in the bad old days, I could not run raw file systems because Linux did not support them) because the unnecessary journalling has a small, but noticeable overhead in addition to the ext2 overhead. My guess is that Oracle is running raw IO, then, which can have much lower IO cost because it reads and writes to contiguous areas of disk, can do IO in much larger blocks, and thereby reduce the seek time, the number of IO operations (especially the cost of any journalling, since a dbms does that by iteslf anyway), and keeping inodes, etc., up to date. In a typical UNIX file system, anytime you read or write a file, it must update the most recently written and accessed information, and this has a real IO cost. Not a problem when typing source code into a text editor, but could be a major headache if running a dbms.

My guess, therefore, is that iostat is reporting correctly and you have efficient hard drives and IO channels. I am impressed, though. I suppose it could be a bug. But I would have to know a lot more about your machine, Oracle, and your useage patterns to really answer it (and, mostly, I do not want to know, since I have never used Oracle). You might wish to ask Oracle about it as they almost certainly know what their product does. I buttume Oracle (who are not johnny come latelys) know how to run raw io for their database. RHEL3 can also do that. Perhaps you just need to configure your dbms to use it (if you are not doing it already).

-- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 07:45:00 up 6 days, 47 min, 3 users, load average: 4.16, 4.20, 4.17