Title: RE: SunOS 5.8 I/O buffer size?

Yeah, I've been using this device for backups for
years.  Always get very good performance.



(This is a joke folks!)

----
Matt Adams - GE Appliances - [EMAIL PROTECTED]
When someone says "I want a programming language in which I
only need say what I want done",  give him a lollipop.

-----Original Message-----
From: Jared Still [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 14, 2002 11:18 AM
To: Multiple recipients of list ORACLE-L
Subject: 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" <[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: Jared Still
  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).

Reply via email to