RE: SunOS 5.8 I/O buffer size?

Tim, I don't believe that you can see that by strace. The whole thing is happening entirely in the kernel. The problem is that each device has a fixed size buffer allocated in the kernel address space. When you allocate user buffer, it's contents it being copied to either the buffer cache (file system) or the drive buffer from which driver writes the data to the disk when the buffer is full. The process is repeated as long as necessary to get the user buffer written to the disk. Evertything happens within the system call. Size of the maximum atomic write is the size of that buffer that is allocated per device. I think htat the only way to find that out is to contact SUN support. HP support, for instance, tells me that that on HP-UX 11 (64 bit) the maximum size is 1MB.

> -----Original Message-----
> From: Tim Gorman [mailto:Tim_at_SageLogix.com]
> Sent: Thursday, June 13, 2002 10:13 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: SunOS 5.8 I/O buffer size?
>
>
> 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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Gogala, Mladen
  INET: MGogala_at_oxhp.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).