Carmen et al,
Did some testing on this. On solaris 2.8 there doesn't seem to be any
upper-limit on single, atomic disk I/O, probably because someone finally got
smart and started allocating memory buffers for I/O dynamically using the
"malloc()" package instead of hard-coding a fixed-length variable as a
buffer. At least, they did so for the "dd" command...
Ran the following, reading three 1024Kb "chunks" from a large file while
"truss"ing the UNIX "dd" command:
$ truss -D dd if=/d01001/oradata/portal/portal_01.dbf of=/dev/null bs=1024k
count=3
0.0000 execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
0.0036 mmap(0x00000000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A0000
0.0005 resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
0.0006 open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
0.0004 open("/usr/lib/libc.so.1", O_RDONLY) = 3
0.0003 fstat(3, 0xFFBEF3C4) = 0
0.0002 mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF390000
0.0003 mmap(0x00000000, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF280000
0.0004 mmap(0xFF33A000, 24784, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 696320) = 0xFF33A000
0.0005 munmap(0xFF32A000, 65536) = 0
0.0007 memcntl(0xFF280000, 113272, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
0.0003 close(3) = 0
0.0003 open("/usr/lib/libdl.so.1", O_RDONLY) = 3
0.0003 fstat(3, 0xFFBEF3C4) = 0
0.0003 mmap(0xFF390000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0) = 0xFF390000
0.0004 close(3) = 0
0.0004 open("/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1", O_RDONLY) =
3
0.0004 fstat(3, 0xFFBEF254) = 0
0.0003 mmap(0x00000000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF380000
0.0003 mmap(0x00000000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF370000
0.0004 close(3) = 0
0.0015 munmap(0xFF380000, 8192) = 0
0.0009 brk(0x00023F68) = 0
0.0003 brk(0x00025F68) = 0
0.0005 open64("/d01001/oradata/portal/portal_01.dbf", O_RDONLY) = 3
0.0004 creat64("/dev/null", 0666) = 4
0.0004 sysconfig(_CONFIG_PAGESIZE) = 8192
0.0003 brk(0x00025F68) = 0
0.0002 brk(0x00127F68) = 0
0.0004 sigaction(SIGINT, 0xFFBEFA70, 0xFFBEFAF0) = 0
0.0002 sigaction(SIGINT, 0xFFBEFA70, 0xFFBEFAF0) = 0
0.0985 read(3, "\0\0\0\0\0\0 \0\0\0 }80".., 1048576) = 1048576
0.0005 write(4, "\0\0\0\0\0\0 \0\0\0 }80".., 1048576) = 1048576
0.0777 read(3, "\002\0\0\0\0\080\0\0\0\0".., 1048576) = 1048576
0.0005 write(4, "\002\0\0\0\0\080\0\0\0\0".., 1048576) = 1048576
0.0744 read(3, "0602\0\0028001\0\003 > s".., 1048576) = 1048576
0.0004 write(4, "0602\0\0028001\0\003 > s".., 1048576) = 1048576
0.0004 close(4) = 0
0.0003 close(1) = 0
3+0 0.0006 write(2, " 3 + 0", 3) = 3
records in
0.0004 write(2, " r e c o r d s i n\n", 12) = 12
3+0 0.0006 write(2, " 3 + 0", 3) = 3
records out
0.0003 write(2, " r e c o r d s o u t".., 13) = 13
0.0006 llseek(0, 0, SEEK_CUR) = 37672
0.0002 _exit(0)
Note that each of the three "read()" and "write()" calls use 1048576 bytes
(i.e. 1024 Kbytes) apiece. Please also note the two "brk()" calls, which
allocate more memory to the process heap from the O/S, probably through the
"malloc()" package. Last, please note the elapsed time (i.e. "-D" option on
"truss") for the three "read()" calls are 0.0985, 0.0777, and 0.0744 seconds
respectively.
Next, I tried making the requested read size 10x bigger...
$ truss -D dd if=/d01001/oradata/portal/portal_01.dbf of=/dev/null bs=10240k
count=3
0.0000 execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
...
0.8446 read(3, "\0\0\0\0\0\0 \0\0\0 }80".., 10485760) = 10485760
0.0006 write(4, "\0\0\0\0\0\0 \0\0\0 }80".., 10485760) = 10485760
0.8052 read(3, "0602\0\0028005\0\0\f R c".., 10485760) = 10485760
0.0006 write(4, "0602\0\0028005\0\0\f R c".., 10485760) = 10485760
0.7454 read(3, "\002\0\0\0\0\n\0\0\0\0\0".., 10485760) = 10485760
0.0006 write(4, "\002\0\0\0\0\n\0\0\0\0\0".., 10485760) = 10485760
...
Please note that the third argument to the "read()" and "write()" calls is
now 10 Mbytes (i.e. 10,485,760 bytes) and that the elapsed time for the
three calls are now about 10x slower at 0.8446, 0.8052, and 0.7454 seconds
respectively.
So, it seems that Solaris 2.8 doesn't split large I/O requests into smaller
ones. What would be interesting would be whether older versions of Solaris
did so. Would someone running on Sol 2.5.x, 2.6, and 2.7 be able to try
this same test and post the results back to the list. Also, would those on
other platforms care to try the test?
Thanks!
-Tim
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, June 12, 2002 8:33 AM
> The "IO buffer size" is the maximal size of a single, atomic disk IO,
> usually
> either 128k or 256k. All IO requests larger then that will be
> internally broken
> into multiple requests. As my Solaris is getting rusty (working with
> HP-UX and
> Linux now) I cannot remember the exact parameter name. It used to be
> available
> in the "Ferrari" book.
>
>
> On 2002.06.12 09:53 Carmen Rusu wrote:
> >
> > Kevin Loney's Oracle8i DBA Handbook says you need to know the
> > "operating system's I/O buffer size" in order to set the init param
> > DB_FILE_MULTIBLOCK_READ_COUNT correctly.
> >
> > What is the definition of "operating system's I/O buffer size Loney is
> > talking about?
> >
> > What is the value of " I/O buffer size" for SunOS 5.8?
> >
> > Went to Sun's web site and got lost...I just want two straight answers
> > to my two questions.
> >
> >
> >
> >
> > Thanks,
> >
> > Carmen Rusu
> > Sr Oracle DBA
> > 512-463-3657 (office)
> > 512-606-5012 (pager)
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Carmen Rusu
> > INET: [EMAIL PROTECTED]
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
> >
>
> --
> Mladen Gogala
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Mladen Gogala
> INET: [EMAIL PROTECTED]
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tim Gorman
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
