Re: SunOS 5.8 I/O buffer size?

Hi Tim

Here are numbers for a Redhat 7.2 Linux with kernel 2.4.17 using LVM1.0.3 on the disk.
There is something rotten here since the read time is not increasing with a factor 10 as I would
expect the write time is behaving close to expected. If you want the full strace drop a mail.

    1 Mb Read / Write
    0.000000 execve("/bin/dd", ["dd", "if=system01.dbf", "of=/dev/null", "bs=1024k", "count=10"], [/* 29 vars */]) = 0

    ..,
    0.000084 read(0, "\2\0\0\0\0

\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 1048576) = 1048576
    0.018887 write(1, "\2\0\0\0\0 
\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 1048576) = 1048576

    0.000105 read(0,
"\6\2\0\0\200\0@\0\330y\3\0\0\0\1\0065\32\0\0\1\0\0\0\22"..., 1048576) = 1048576

    0.007667 write(1,
"\6\2\0\0\200\0@\0\330y\3\0\0\0\1\0065\32\0\0\1\0\0\0\22"..., 1048576) = 1048576

    0.000107 read(0,
"\0\2\0\0\0\1\0\0\0\0\0\0\0\0\1\5\0\6\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576

    0.005537 write(1,
"\0\2\0\0\0\1\0\0\0\0\0\0\0\0\1\5\0\6\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576

    0.000182 read(0,
"\0\2\0\0\200\1\0\0\0\0\0\0\0\0\1\5\200\6\0\0\0\0\0\0\0"..., 1048576) = 1048576

    0.008132 write(1,
"\0\2\0\0\200\1\0\0\0\0\0\0\0\0\1\5\200\6\0\0\0\0\0\0\0"..., 1048576) = 1048576

    0.000140 read(0,
"\6\2\0\0\0\2@\0\331[\3\0\0\0\2\4\207%\0\0\1\0(\0D\0\0\0"..., 1048576) = 1048576

    0.007741 write(1,
"\6\2\0\0\0\2@\0\331[\3\0\0\0\2\4\207%\0\0\1\0(\0D\0\0\0"..., 1048576) = 1048576

    0.000113 read(0,
"\0\2\0\0\200\2\0\0\0\0\0\0\0\0\1\5\200\5\0\0\0\0\0\0\0"..., 1048576) = 1048576

    10 Mb Read / Write

    0.000000 execve("/bin/dd", ["dd", "if=system01.dbf", "of=/dev/null", "bs=10240k","count=10"], [/* 29 vars */]) = 0

    ..
    0.000086 read(0, "\2\0\0\0\0

\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 10485760) = 10485760
    0.084090 write(1, "\2\0\0\0\0 
\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 10485760) = 10485760

    0.000110 read(0,
"\0\2\0\0\0\5\0\0\0\0\0\0\0\0\1\5\0\2\0\0\0\0\0\0\0\0\0"..., 10485760) = 10485760

    0.073709 write(1,
"\0\2\0\0\0\5\0\0\0\0\0\0\0\0\1\5\0\2\0\0\0\0\0\0\0\0\0"..., 10485760) = 10485760

    0.000160 read(0,
"\0\2\0\0\0\n\0\0\0\0\0\0\0\0\1\5\0\r\0\0\0\0\0\0\0\0\0"..., 10485760) = 10485760

    0.070780 write(1,
"\0\2\0\0\0\n\0\0\0\0\0\0\0\0\1\5\0\r\0\0\0\0\0\0\0\0\0"..., 10485760) = 10485760

    0.000569 read(0,
"\0\2\0\0\0\17\0\0\0\0\0\0\0\0\1\5\0\10\0\0\0\0\0\0\0\0"..., 10485760) = 10485760

    0.071877 write(1,
"\0\2\0\0\0\17\0\0\0\0\0\0\0\0\1\5\0\10\0\0\0\0\0\0\0\0"..., 10485760) = 10485760

    0.000154 read(0,
"\6\2\0\0\0\24@\0\236(\1\0\0\0\2\4\264\357\0\0\1\0\0\0>"..., 10485760) = 10485760

    0.071539 write(1,
"\6\2\0\0\0\24@\0\236(\1\0\0\0\2\4\264\357\0\0\1\0\0\0>"..., 10485760) = 10485760

    0.000157 read(0,
"\6\2\0\0\0\31@\0{N\1\0\0\0\2\4\265\222\0\0\1\0\0\0J\0\0"..., 10485760) = 10485760

Tim Gorman wrote:

>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" <ORACLE-L_at_fatcity.com>
>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: carmen.rusu_at_rrc.state.tx.us
>>>
>>>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: ListGuru_at_fatcity.com (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: mgogala_at_adelphia.net
>>
>>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: ListGuru_at_fatcity.com (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).
>>
>>
>
>
>

-- 

/regards

Peter Gram

Mobil : +45 2527 7107
Fax   : +45 4466 8856

Miracle A/S
Kratvej 2
2760 Måløv
http://miracleas.dk

/*
The process of preparing programs for a digital computer is especially
attractive, not only because it can be economically and scientifically
rewarding, but also because it can be an aesthetic experience much like 
composing poetry or music

Donald Knuth
*/ 





Content-Type: text/plain; name="ReadMe.txt"; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The previous attachment was filtered out by the ListGuru mailing
software at fatcity.com because binary attachments are not appropriate
for mailing lists.  If you want a copy of the attachment which was
removed, contact the sender directly and ask for it to be sent to
you by private E-mail.

This warning is inserted into all messages containing binary
attachments which have been removed by ListGuru.  If you have questions
about this message, contact Postmaster_at_fatcity.com for clarification.

--------------ms000605080903090209080705--

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Peter Gram
  INET: peter.gram_at_miracleas.dk

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: ListGuru_at_fatcity.com (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).



application/x-pkcs7-signature attachment: smime.p7s