RE: SunOS 5.8 I/O buffer size?
That's it, I *must* read that copy of "The Magic Garden Explained"
that is at home langushing on the shelf.
Jared
"Gogala, Mladen" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/14/2002 10:03 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: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:[EMAIL PROTECTED]]
> 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. execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
> 0.0036 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> 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(0x, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF39
> 0.0003 mmap(0x, 794624, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF28
> 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED,
> 3, 0) = 0xFF39
> 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(0x, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF38
> 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF37
> 0.0004 close(3)= 0
> 0.0015 munmap(0xFF38, 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 >
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:[EMAIL PROTECTED]]
> 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. execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
> 0.0036 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> 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(0x, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF39
> 0.0003 mmap(0x, 794624, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF28
> 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED,
> 3, 0) = 0xFF39
> 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(0x, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF38
> 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF37
> 0.0004 close(3)= 0
> 0.0015 munmap(0xFF38, 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)
RE: SunOS 5.8 I/O buffer size?
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.5 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. execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
> 0.0036 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> 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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF39
> 0.0003 mmap(0x, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF28
> 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
> 3, 0) = 0xFF39
> 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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF38
> 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF37
> 0.0004 close(3) = 0
> 0.0015 munmap(0xFF38, 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 "
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.5 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. execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
> 0.0036 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> 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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF39
> 0.0003 mmap(0x, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF28
> 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
> 3, 0) = 0xFF39
> 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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF38
> 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF37
> 0.0004 close(3)= 0
> 0.0015 munmap(0xFF38, 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. 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
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" <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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. execve("/usr/bin/dd", 0xFFBEFC8C,
> > 0xFFBEFCA4) argc = 5
> > 0.0036 mmap(0x, 8192,
> > PROT_READ|PROT_WRITE|PROT_EXEC,
> > MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> > 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(0x, 8192, PROT_READ|PROT_EXEC,
> > MAP_PRIVATE, 3, 0) =
> > 0xFF39
> > 0.0003 mmap(0x, 794624,
> > PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> > 0xFF28
> > 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC,
> > MAP_PRIVATE|MAP_FIXED,
> > 3, 0) = 0xFF39
> > 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(0x, 8192, PROT_READ|PROT_EXEC,
> > MAP_PRIVATE, 3, 0) =
> > 0xFF38
> > 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC,
> > MAP_PRIVATE, 3, 0) =
> > 0xFF37
> > 0.0004 close(3)
> >= 0
> > 0.0015 munmap(0xFF38, 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
> >
Re: SunOS 5.8 I/O buffer size?
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 <[EMAIL PROTECTED]> 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. execve("/usr/bin/dd", 0xFFBEFC8C,
> 0xFFBEFCA4) argc = 5
> 0.0036 mmap(0x, 8192,
> PROT_READ|PROT_WRITE|PROT_EXEC,
> MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> 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(0x, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF39
> 0.0003 mmap(0x, 794624,
> PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
> 0xFF28
> 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE|MAP_FIXED,
> 3, 0) = 0xFF39
> 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(0x, 8192, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF38
> 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC,
> MAP_PRIVATE, 3, 0) =
> 0xFF37
> 0.0004 close(3)
>= 0
> 0.0015 munmap(0xFF38, 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
>
Re: SunOS 5.8 I/O buffer size?
Hi Tim
Here are numbers for a Redhat 7.2 Linux with kernel 2.4.17 using
LVM1.0.3 on the disk.
There is something rotten here since the read time is not increasing
with a factor 10 as I would
expect the write time is behaving close to expected.
If you want the full strace drop a mail.
1 Mb Read / Write
0.00 execve("/bin/dd", ["dd", "if=system01.dbf", "of=/dev/null",
"bs=1024k", "count=10"], [/* 29 vars */]) = 0
..,
0.84 read(0, "\2\0\0\0\0
\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 1048576) = 1048576
0.018887 write(1, "\2\0\0\0\0
\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 1048576) = 1048576
0.000105 read(0,
"\6\2\0\0\200\0@\0\330y\3\0\0\0\1\0065\32\0\0\1\0\0\0\22"..., 1048576) =
1048576
0.007667 write(1,
"\6\2\0\0\200\0@\0\330y\3\0\0\0\1\0065\32\0\0\1\0\0\0\22"..., 1048576) =
1048576
0.000107 read(0,
"\0\2\0\0\0\1\0\0\0\0\0\0\0\0\1\5\0\6\0\0\0\0\0\0\0\0\0"..., 1048576) =
1048576
0.005537 write(1,
"\0\2\0\0\0\1\0\0\0\0\0\0\0\0\1\5\0\6\0\0\0\0\0\0\0\0\0"..., 1048576) =
1048576
0.000182 read(0,
"\0\2\0\0\200\1\0\0\0\0\0\0\0\0\1\5\200\6\0\0\0\0\0\0\0"..., 1048576) =
1048576
0.008132 write(1,
"\0\2\0\0\200\1\0\0\0\0\0\0\0\0\1\5\200\6\0\0\0\0\0\0\0"..., 1048576) =
1048576
0.000140 read(0,
"\6\2\0\0\0\2@\0\331[\3\0\0\0\2\4\207%\0\0\1\0(\0D\0\0\0"..., 1048576) =
1048576
0.007741 write(1,
"\6\2\0\0\0\2@\0\331[\3\0\0\0\2\4\207%\0\0\1\0(\0D\0\0\0"..., 1048576) =
1048576
0.000113 read(0,
"\0\2\0\0\200\2\0\0\0\0\0\0\0\0\1\5\200\5\0\0\0\0\0\0\0"..., 1048576) =
1048576
10 Mb Read / Write
0.00 execve("/bin/dd", ["dd", "if=system01.dbf", "of=/dev/null",
"bs=10240k","count=10"], [/* 29 vars */]) = 0
..
0.86 read(0, "\2\0\0\0\0
\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 10485760) = 10485760
0.084090 write(1, "\2\0\0\0\0
\0\0\0\310\0\0]\\[Z\0\0\0\0\4\356\0\0\0\0\0"..., 10485760) = 10485760
0.000110 read(0,
"\0\2\0\0\0\5\0\0\0\0\0\0\0\0\1\5\0\2\0\0\0\0\0\0\0\0\0"..., 10485760) =
10485760
0.073709 write(1,
"\0\2\0\0\0\5\0\0\0\0\0\0\0\0\1\5\0\2\0\0\0\0\0\0\0\0\0"..., 10485760) =
10485760
0.000160 read(0,
"\0\2\0\0\0\n\0\0\0\0\0\0\0\0\1\5\0\r\0\0\0\0\0\0\0\0\0"..., 10485760) =
10485760
0.070780 write(1,
"\0\2\0\0\0\n\0\0\0\0\0\0\0\0\1\5\0\r\0\0\0\0\0\0\0\0\0"..., 10485760) =
10485760
0.000569 read(0,
"\0\2\0\0\0\17\0\0\0\0\0\0\0\0\1\5\0\10\0\0\0\0\0\0\0\0"..., 10485760) =
10485760
0.071877 write(1,
"\0\2\0\0\0\17\0\0\0\0\0\0\0\0\1\5\0\10\0\0\0\0\0\0\0\0"..., 10485760) =
10485760
0.000154 read(0,
"\6\2\0\0\0\24@\0\236(\1\0\0\0\2\4\264\357\0\0\1\0\0\0>"..., 10485760) =
10485760
0.071539 write(1,
"\6\2\0\0\0\24@\0\236(\1\0\0\0\2\4\264\357\0\0\1\0\0\0>"..., 10485760) =
10485760
0.000157 read(0,
"\6\2\0\0\0\31@\0{N\1\0\0\0\2\4\265\222\0\0\1\0\0\0J\0\0"..., 10485760)
= 10485760
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. execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
> 0.0036 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
>MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
> 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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>0xFF39
> 0.0003 mmap(0x, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>0xFF28
> 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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
>3, 0) = 0xFF39
> 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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>0xFF38
> 0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
>0xFF37
> 0.000
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. execve("/usr/bin/dd", 0xFFBEFC8C, 0xFFBEFCA4) argc = 5
0.0036 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF39
0.0003 mmap(0x, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF28
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(0xFF28, 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(0xFF39, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
3, 0) = 0xFF39
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(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF38
0.0003 mmap(0x, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF37
0.0004 close(3)= 0
0.0015 munmap(0xFF38, 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. 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 Sola
RE: SunOS 5.8 I/O buffer size?
Well, I must admit that I drive Hyundai Elantra. I drove VW Golf, Toyota Corola and Citroen ZX. I cannot tell a Ferrari from a Porsche, those cars are not in my class. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 4:53 PM > To: Multiple recipients of list ORACLE-L > Subject: Re: SunOS 5.8 I/O buffer size? > > > Amazing how so many can't tell a Ferrari from a Porsche. > > Not you Mladen, I realize that's why "Ferrari" was in quotes. > > Jared > > > > > > Mladen Gogala <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 06/12/2002 07:33 AM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > cc: > Subject:Re: SunOS 5.8 I/O buffer size? > > > 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: > 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: Gogala, Mladen 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).
Re: SunOS 5.8 I/O buffer size?
Amazing how so many can't tell a Ferrari from a Porsche.
Not you Mladen, I realize that's why "Ferrari" was in quotes.
Jared
Mladen Gogala <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
06/12/2002 07:33 AM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: Re: SunOS 5.8 I/O buffer size?
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:
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).
Re: SunOS 5.8 I/O buffer size?
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).
