Re: 10g System statistics - single and multi
- From: Christo Kutrovsky <kutrovsky.oracle@xxxxxxxxx>
- To: Wolfgang Breitling <breitliw@xxxxxxxxxxxxx>
- Date: Wed, 18 May 2005 16:15:15 -0400
Ah !=20
I know understand the flaw of your test OR the flaw of my
understanding for sread vs mread.
before i start.
>I don't quite understand how to read this. what does, e.g., "8k read-1"
>mean as opposed to "8k read-4"?
8k read-1 - request 1 io, wait for answer, request 1 io, wait for answer...=
etc.
8k read-4 - request 4 ios, wait for 1 io answer and send another
request... etc. In such away, that there would be always 4 pending IO
requests.
Basically async IO. In the Oracle world, that would be multiple
sessions doing IO. Or the dbwriter with asyncIO enabled.
The problem with our discussion is our assumptions.
My assumption:
sread =3D "db file sequencial read" =3D Random IO from say, an INDEX range
scan accessing the table. (not the range scan itself, as on a freshly
rebuild index, the range scan will be almost sequencial IO, but the
table access will probably be random IO)
mread =3D "db file scattered read" =3D sequencial IO =3D Full table scan or
full index scan.
Your assumption (i could be wrong, i concluded that this is your
assumption based on the test you are doing, and the timings you were
observing)
sread =3D single block access, could be resulting from a dfmrc been 1.
I.e. could be either RANDOM or SEQUENCIAL IO.
mread =3D sequencial IO with dfmrc > 1
Basically your test shows the benefit of uding dfmrc, and shows how
even at the last step, doubling from 64 to 128, the time increases
only 1.88 times, i.e. still some benefit from large reads.
My tests however, show disk times of RANDOM access. Which is very
different, from your tests, which test disk times of SEQUENCIAL
access, with different IO sizes.
Makes sense ?
On 5/18/05, Wolfgang Breitling <breitliw@xxxxxxxxxxxxx> wrote:
> Christo,
>=20
> my test was very simple and crude. I did for example not repeat it
> several times to get averages. I am not familiar with iometer, I just
> use Oracle to give me the timings, since it is also Oracle which will
> gather the timing for the system statistics, so the ela values are
> microseconds for a single block (sequential) read. The values are
> actually averages for all single block reads. Likewise, the other ela
> values are averages over their respective occurences. I redid the test,
> clearing the buffer between different dfrmc settings (by offlining the
> tablespace) and also ran the entire test twice and then also ran it with
> the tablespace on an EMC CX700. The findings are still the same, the
> hogher the number of blocks read with one IO (as seen from Oracle), the
> longer it takes =3D> mreadtm > sreadtm
>=20
> EMC CX700:
>=20
> dfmrc count elapsed (usec)
> 1 1985 297.355
> 3 1 300.000
> 8 241 564.423
> 11 4 747.000
> 16 120 989.733
> 32 60 1,771.250
> 64 30 3,241.100
> 128 15 6,295.133
>=20
> 1 1985 288.202
> 3 1 291.000
> 8 241 605.867
> 11 4 733.750
> 16 120 935.692
> 32 60 1,714.833
> 64 30 3,234.767
> 128 15 6,199.000
>=20
> IBM ESS 700 (Shark):
>=20
> dfmrc count elapsed (usec)
> 1 1965 545.717
> 7 1 1,130.000
> 8 241 1,283.353
> 15 1 2,417.000
> 16 123 2,637.959
> 31 1 4,478.000
> 32 59 4,715.203
> 63 1 8,088.000
> 64 29 8,294.862
> 127 1 16,496.000
> 128 14 16,250.071
>=20
> 1 1967 693.753
> 7 1 1,126.000
> 8 241 1,293.324
> 15 1 2,815.000
> 16 123 2,647.301
> 31 1 4,401.000
> 32 59 4,701.898
> 63 1 8,111.000
> 64 29 8,250.310
> 127 1 15,436.000
> 128 14 15,570.214
>=20
> The tablespace on the shark is an LMT with a 4M uniform extent size and
> the table spans 4 extents. The tablespace on the cx700 is an LMT with a
> 32M uniform extent size. That explains the differences in the read patter=
ns.
>=20
> Christo Kutrovsky wrote:
>=20
> > Wolfgang,
> >
> > These results have been produced with Windows (for convenience) on
> > unpartitioned drives with iometer (www.iometer.org). No caching on OS
> > side.
> >
> > Random read from my SAN
> > Test type Responce time (ms)
> > 512 read-1 0.874
> > 512 read-2 0.173
> > 512 read-4 0.130
> > 8k read-1 0.457
> > 8k read-2 0.149
> > 8k read-4 0.228
> > 32k read-1 0.422
> > 32k read-2 0.388
> > 32k read-4 0.762
> > 256k read-1 2.165
> > 256k read-2 2.672
> > 256k read-4 5.185
> >
>=20
> I don't quite understand how to read this. what does, e.g., "8k read-1"
> mean as opposed to "8k read-4"?
>=20
> --
> Regards
>=20
> Wolfgang Breitling
> Centrex Consulting Corporation
> www.centrexcc.com
>=20
--=20
Christo Kutrovsky
Database/System Administrator
The Pythian Group
--
//www.freelists.org/webpage/oracle-l
Other related posts:
