Return-Path: Delivered-To: 2-oracle-l@orafaq.com Received: (qmail 11246 invoked from network); 12 Dec 2006 09:17:09 -0600 Received: from freelists-180.iquest.net (HELO turing.freelists.org) (206.53.239.180) by 69.64.49.119 with SMTP; 12 Dec 2006 09:17:05 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 7A6195649E0; Tue, 12 Dec 2006 10:16:08 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09954-07; Tue, 12 Dec 2006 10:16:08 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D50C65661DA; Tue, 12 Dec 2006 10:16:07 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Tue, 12 Dec 2006 10:15:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 6AD56564612 for ; Tue, 12 Dec 2006 10:15:03 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09552-04 for ; Tue, 12 Dec 2006 10:15:03 -0500 (EST) Received: from sxexscan2.qg.com (MAIL.openfirst.com [161.49.252.5]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D98D3565F97 for ; Tue, 12 Dec 2006 10:15:02 -0500 (EST) Received: from unknown (HELO waexsmtp2.qg.com) ([192.168.3.29]) by sxexscan2.qg.com with ESMTP; 12 Dec 2006 09:17:46 -0600 X-IronPort-AV: i="4.09,525,1157346000"; d="scan'208,217"; a="80708025:sNHT32832289" Received: from SXEXPF1.qg.com ([172.25.24.223]) by waexsmtp2.qg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 09:15:56 -0600 Received: from QTEX1.qg.com ([172.25.130.31]) by SXEXPF1.qg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 09:15:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71E00.6BDC6E6E" Subject: RE: I/O and db_file_multiblock_read_count Date: Tue, 12 Dec 2006 09:15:56 -0600 Message-ID: In-Reply-To: <5D2570CAFC98974F9B6A759D1C74BAD001C33775@ex2.ms.polyserve.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I/O and db_file_multiblock_read_count From: "Jesse, Rich" To: , "oracle-l" X-OriginalArrivalTime: 12 Dec 2006 15:15:56.0619 (UTC) FILETIME=[6C1F91B0:01C71E00] X-TM-AS-Product-Ver: SMEX-7.0.0.1499-3.6.1039-14868.003 X-TM-AS-Result: No--9.705500-0.000000-1 X-archive-position: 43033 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: Rich.Jesse@qg.com Precedence: normal Reply-to: Rich.Jesse@qg.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at avenirtech.net ------_=_NextPart_001_01C71E00.6BDC6E6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm guessing that I'm limited by CPU on this IBM JS21 blade's LPAR (MPV, 2 cores max) with an SVC (virtualized SAN) backend. topas showed kernel mode CPU >95% for most of the tests. =20 /oracle $ time dd if=3DS.dbf of=3D/dev/zero bs=3D1024k 16384+1 records in 16384+1 records out =20 real 1m3.044s user 0m0.271s sys 0m42.458s /oracle $ time dd if=3DS.dbf of=3D/dev/zero bs=3D1024k 16384+1 records in 16384+1 records out =20 real 1m2.923s user 0m0.249s sys 0m42.325s t/oracle $ time dd if=3DS.dbf of=3D/dev/zero bs=3D128k 131072+1 records in 131072+1 records out =20 real 1m2.789s user 0m0.709s sys 0m41.665s /oracle $ time dd if=3DS.dbf of=3D/dev/zero bs=3D128k 131072+1 records in 131072+1 records out =20 real 1m2.497s user 0m0.688s sys 0m41.422s /oracle $ time dd if=3DS.dbf of=3D/dev/zero bs=3D8192k 2048+1 records in 2048+1 records out =20 real 1m2.601s user 0m0.106s sys 0m41.666s /oracle $ time dd if=3DS.dbf of=3D/dev/zero bs=3D8192k 2048+1 records in 2048+1 records out =20 real 1m2.628s user 0m0.099s sys 0m41.621s Rich ________________________________ From: oracle-l-bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Kevin Closson Sent: Monday, December 11, 2006 3:19 PM To: oracle-l Subject: RE: I/O and db_file_multiblock_read_count OK, we should all throw our dd(1) microbenchmark results out there... This is a DL-585 with 2Gb FCP to a PolyServe CFS monted in direct I/O mode. The single LUN is RAID 1+0 st_width 1MB striped across 65 15K RPM drives (hey, I get to play with nice toys...) =20 The file is 16GB=20 =20 $ time dd if=3Df1 of=3D/dev/zero bs=3D1024k 16384+0 records in 16384+0 records out =20 real 1m47.220s user 0m0.009s sys 0m5.175s $ time dd if=3Df1 of=3D/dev/zero bs=3D128k 131072+0 records in 131072+0 records out =20 real 2m52.157s user 0m0.056s sys 0m7.126s For grins I through in huge I/O sizes (yes this is acutally issuing 8MB blocking reads) =20 $ $ time dd if=3Df1 of=3D/dev/zero bs=3D8192k 2048+0 records in 2048+0 records out =20 real 1m32.710s user 0m0.002s sys 0m3.984s =20 Large I/Os get chopped up in the scsi midlayer of Linux, but like what is happening if you get less tput with larger I/Os is you have few drives and a stripe with that is causing each disk to be hit more than once for every I/O (that is bad). =20 =20 =20 =20 ------_=_NextPart_001_01C71E00.6BDC6E6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'm guessing that I'm limited by CPU on this IBM JS21 = blade's=20 LPAR (MPV, 2 cores max) with an SVC (virtualized SAN) = backend. =20 topas showed kernel mode CPU >95% for most of the = tests.
 
/oracle $ time dd if=3DS.dbf of=3D/dev/zero = bs=3D1024k
16384+1 records=20 in
16384+1 records out
 
real    1m3.044s
user   =20 0m0.271s
sys     = 0m42.458s
/oracle $ time dd if=3DS.dbf of=3D/dev/zero = bs=3D1024k
16384+1 records=20 in
16384+1 records out
 
real    1m2.923s
user   =20 0m0.249s
sys     0m42.325s

t/oracle $ time dd if=3DS.dbf of=3D/dev/zero = bs=3D128k
131072+1 records=20 in
131072+1 records out
 
real    1m2.789s
user   =20 0m0.709s
sys     0m41.665s

/oracle $ time dd if=3DS.dbf of=3D/dev/zero = bs=3D128k
131072+1 records=20 in
131072+1 records out
 
real    1m2.497s
user   =20 0m0.688s
sys     = 0m41.422s
/oracle $ time dd if=3DS.dbf of=3D/dev/zero = bs=3D8192k
2048+1 records=20 in
2048+1 records out
 
real    1m2.601s
user   =20 0m0.106s
sys     = 0m41.666s
/oracle $ time dd if=3DS.dbf of=3D/dev/zero = bs=3D8192k
2048+1 records=20 in
2048+1 records out
 
real    1m2.628s
user   =20 0m0.099s
sys     = 0m41.621s
Rich

From: oracle-l-bounce@freelists.org=20 [mailto:oracle-l-bounce@freelists.org] On Behalf Of Kevin=20 Closson
Sent: Monday, December 11, 2006 3:19 PM
To:=20 oracle-l
Subject: RE: I/O and=20 db_file_multiblock_read_count

OK, we should all throw our dd(1) = microbenchmark=20 results out there... This
is a DL-585 with 2Gb FCP to a PolyServe CFS = monted in=20 direct I/O mode. The
single LUN is RAID 1+0 st_width 1MB striped = across 65=20 15K RPM drives (hey,
I get to play with nice = toys...)
 
The file is 16GB
 
$ time dd if=3Df1 of=3D/dev/zero = bs=3D1024k
16384+0=20 records in
16384+0 records out
 
real   =20 1m47.220s
user    = 0m0.009s
sys    =20 0m5.175s
$ time dd if=3Df1 of=3D/dev/zero bs=3D128k
131072+0 = records=20 in
131072+0 records out
 
real   =20 2m52.157s
user    = 0m0.056s
sys    =20 0m7.126s
For grins I through in huge I/O sizes (yes = this is=20 acutally issuing 8MB blocking reads)
 
$
$ time dd if=3Df1 of=3D/dev/zero = bs=3D8192k
2048+0=20 records in
2048+0 records out
 
real   =20 1m32.710s
user    = 0m0.002s
sys    =20 0m3.984s
 
Large I/Os get chopped up in the scsi = midlayer of=20 Linux, but like what is happening if you
get less tput with larger I/Os is you have = few drives=20 and a stripe with that is causing each
disk to be hit more than once for every I/O = (that is=20 bad). 
 
 
 
------_=_NextPart_001_01C71E00.6BDC6E6E-- -- http://www.freelists.org/webpage/oracle-l