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