Re: SunOS 5.8 I/O buffer size?

Live and learn! I'd never heard of SSTIOMAX, but there's a decent MetaLink article on it (#131530.1)...

I tried using "nm" and "strings" on the "oracle" executable and many of the ".a" and ".so" objects and couldn't find it mentioned, so it must be a "#define" compiler directive in the source code or something. One of the MetaLink forums stated that it is set:

    7.3.x --> SSTIOMAX = 128K
    8.0.3 --> SSTIOMAX = 512K
    8.0.4 --> SSTIOMAX = 1M

Thanks Connor!

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Friday, June 14, 2002 7:13 AM

> On 2.7
>
> 0.8128 read(3, "\0\0\0\0\0\002\0\0\0F0\0"..,
> 10485760) = 10485760
> 0.1003 write(4, "\0\0\0\0\0\002\0\0\0F0\0"..,
> 10485760) = 10485760
> 0.7603 read(3, "\0\00386\0\0 P\01BAFD0FA"..,
> 10485760) = 10485760
> 0.1039 write(4, "\0\00386\0\0 P\01BAFD0FA"..,
> 10485760) = 10485760
> 1.0187 read(3, "\0\00386\0\0A0\01BAFF486"..,
> 10485760) = 10485760
> 0.1074 write(4, "\0\00386\0\0A0\01BAFF486"..,
> 10485760) = 10485760
>
> But isn't this a moot point - I'm pretty sure SSTIOMAX
> is fixed at 1M for all 'current' Oracle versions
>
> Cheers
> Connor
>
> --- Tim Gorman <Tim_at_SageLogix.com> 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: Tim Gorman
> > INET: Tim_at_SageLogix.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).
>
> =====
> Connor McDonald
> http://www.oracledba.co.uk
> http://www.oaktable.net
>
> "Some days you're the pigeon, some days you're the statue"
>
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: =?iso-8859-1?q?Connor=20McDonald?=
> INET: hamcdc_at_yahoo.co.uk
>
> 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: Tim Gorman
  INET: Tim_at_SageLogix.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).