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).
Received on Fri Jun 14 2002 - 08:13:20 CDT
