Re: 10g System statistics - single and multi
- From: Christo Kutrovsky <kutrovsky.oracle@xxxxxxxxx>
- To: Paul Drake <bdbafh@xxxxxxxxx>
- Date: Wed, 18 May 2005 14:57:30 -0400
FORMATING !!!
For some reason, the TAB sign has been replaced with 09 (HEX) thus all
my numbers were prefixed by 09 !!!! I knew i didn't post these numbers
...
Here's the results with NO TABS
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
I dont have the 512K reads saved. The number after the test is
outstanding IOs. (read async or multiple sessions active).
And the random values are:
512 read RAND-1 252.949
512 read RAND-2 79.780
512 read RAND-4 7.537
8k read RAND-1 6.376
8k read RAND-2 6.978
8k read RAND-4 8.375
32k read RAND-1 7.193
32k read RAND-2 8.399
32k read RAND-4 11.864
256k read RAND-1 1.331
256k read RAND-2 15.278
256k read RAND-4 27.275
On 5/18/05, Paul Drake <bdbafh@xxxxxxxxx> wrote:
> On 5/18/05, Christo Kutrovsky <kutrovsky.oracle@xxxxxxxxx> wrote:
> > Wolfgang,
> >
> > I will have to repeat this test on my system. What was your OS and
> > file system ? linux and ext3 does not have directio support. It also
> > has poor default read-ahead parameters.
> >
> > "...on average it should take the same amount of time to position ..."
> > If you were to do 1 x dfmrc randomly, then yes mread would always be >
> > sread. But you are doing this sequencially. Thus only the 1st read
> > would involve positioning the heads, after that, every subsequent read
> > would not include that time. Every so often, there would be some time
> > to move the head to next track, but this time is far less then a full
> > seek time. That is, of course, assuming no other disk activity. Or
> > minor activity.
> >
> > Unfortunelly the test 10g system I have is not yet on the SAN i am test=
ing.
> >
> > I am using RedHat linux and ASM (i.e. using directio)
> >
> > 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=3D090.874
> > 512 read-2=3D090.173
> > 512 read-4=3D090.130
> > 8k read-1=3D090.457
> > 8k read-2=3D090.149
> > 8k read-4=3D090.228
> > 32k read-1=3D090.422
> > 32k read-2=3D090.388
> > 32k read-4=3D090.762
> > 256k read-1=3D092.165
> > 256k read-2=3D092.672
> > 256k read-4=3D095.185
> >
>=20
> 90 milliseconds for a single IO? what are you using, a 5 year old laptop?
> Can you run a sanity check against sys.V_$FILESTAT to make sure that
> you're on the right order of magnitude?
>=20
> This sounds like you need to watch the movie "Office Space" repeatedly.
> Pay particular attention to the part where Micheal Bolton is chastised
> for not keeping proper track of the decimal (US-centric) point. They
> end up headed for trouble, but predictably so as the movie came out of
> hollywood, they avoid _hard_ time in a federal (pound me ...) prison.
>=20
> You cannot be averaging 90 milliseconds for an IO on a healthy system.
> I don't think that I could get that if I set every parameter
> backwards, disabled all of the indexes and set the
> pga_aggregate_target to 4M. Guess it might be worth a try.
> I guess that its possible if you are running RAID 5. baarf.
>=20
> Paul
>=20
> --
> #/etc/init.d/init.cssd stop
> # f=3Dma, divide by 1, convert to moles.
>=20
--=20
Christo Kutrovsky
Database/System Administrator
The Pythian Group
--
//www.freelists.org/webpage/oracle-l
Other related posts:
