Re: SunOS 5.8 I/O buffer size?

Hey Tim!

That /dev/null device is really fast! Solaris wrote 10 megabytes to it in 0.00005 seconds.

Where can I get one of those?

Jared  

;)

On Thursday 13 June 2002 19:13, 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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jared Still
  INET: jkstill_at_cybcon.com

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).