HP3000-L Archives

November 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Christian Lheureux <[log in to unmask]>
Reply To:
Date:
Tue, 20 Nov 2001 14:23:31 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (147 lines)
I easily understand the shock it may have been when you did the tests. But,
once again, it's got to have a rational explanation, like database master
sets 80%+ full on one box and 30% full on another one (would more than
enough account for the discrepancy as far as inserts are concerned), disc
space and file fragmentation, and many others.

Performance is, as you sure know, a complex domain where dozens of factors
influence each other.

Hmmmmm ... theory of chaos brought in here at this stage ... could it be
possible that a slight difference in, say, the occupation and media record
spread around the key value in master sets, would produce such unexpected
results ?

Alfredo (and others), care to comment ?

The 969/200 (two-way, "small" cache) has a perf index of 9.2. The 969/220
(two-way, "large" cache) has an index of 12.4. So they're easily the most
powerful beasts in the herd. See my complete chart, posted by Jon Backus on
the TechGroup site for details. The exact URL is
http://www.techgroupmd.com/HP3000PerfSpec.htm.

Christian Lheureux
Responsable du Departement Systemes et Reseaux / Head of Systems and
Networks Department
APPIC R.H.
business partner hp invent
Tel : +33-1-69-80-97-22   /   Fax : +33-1-69-80-97-14 / e-mail :
[log in to unmask]
"Le Groupe APPIC recrute, contactez nous !"



> -----Message d'origine-----
> De : [log in to unmask] [mailto:[log in to unmask]]
> Envoye : mardi 20 novembre 2001 13:46
> A : [log in to unmask]; [log in to unmask]
> Objet : Re: [HP3000-L] 7.0 Performance hit?
>
>
> In a message dated 11/20/01 5:12:36 AM Eastern Standard Time,
> [log in to unmask] writes:
>
> <<
>  Several factors should be considered :
>
>  - Are all the runs manipulating the same data ? The same
> amount of data ?
>  The same data structures ?
> {~~~~~
> { The same data base structure, the same software.
> { The copies of the data on the 960 and N220 are a little
> older and a little
> smaller.
> {~~~~~
>  - How many CPUs does your 969 have ?
> {~~~~~
> { The 969 has two CPUs and MRP is running simultaneously in
> two separate
> { accounts, each with its own data.  The comparisons are for the same
> { account on each machine.
> {~~~~~
> - What are your runs exactly doing ? Read-only ? Read/update ? Adds ?
> {~~~~~
> { All the stuff that MRP does.  Lots of reading and updating,
> and a fair
> amount
> { of adding (the week's requisitions, all sorts of data sets
> and flat files
> that get
> { filled with data for reporting, etc.
> {~~~~~
>  - How much free space on each box ?
>  - How fragmented is your disk space on all systems ?
>  - How fragmented are your data files (i.e. how many extents,
> and how spread
>  are the extents ?)
> {~~~~~
> { The N220 is brand new, and MRP is just about the first
> thing tried after
> the
> { data was loaded from backup tapes.  So there wasn't much chance for
> { fragmentation.  I'd have to go back and check the amount of
> free space,
> { but with 114 Gb of disc on the N220 I'm sure there is a LOT
> of space there.
> {~~~~~
>  - How are data/index files implemented ? Separate spindles ?
> {~~~~~
> { Whichever spindles RESTORE put them on.
> {~~~~~
>  - What about storage ? HP-IB ? HP-FL ? SCSI/SE ? F/W ? HVD ? LVD ?
> {~~~~~
> { No more HP-IB or HP-FL, even on the 960, which I think is all F/W
> { I'd have to check on the disc drives.
> {~~~~~
>
>  Here are a few performance indices :
>
>  - 960 = 1.9
>  - N400-220 = 9.0
>  - 969/100 (one-way) = 5.2
>  - 969/420 (four-way) = 21.5
>
>  In other words, we may or may not have comparable
> propositions. I would tend
>  to think that 7.0 has a performance hit, but, from the
> technical data I've
>  had, i would expect a very moderate perf hit.
> {~~~~~
> { Of course they are not comparable, but they are what we have.
> { I've heard that performance hits with 6.5 and 7.0 might be
> around 20%
> {~~~~~
>
>  In other words, a careful look should be taken at these
> runs. There may be
>  some misunderstanding or lack of knowledge of something
> (Hardware config ?
>  Disk space management ?). Or there may be a real perf hit
> (I'm not ruling it
>  out flatly), but it has to be proved. There are lots of
> tools to assist you
>  : HP's Glance Plus and Glane Plus Pak, SPT (for individual
> processes - but
>  that may be moot since I assume the same code is used on all
> three boxes),
>  PerfView (uses Scope as a collection tool), and third party
> tools like SOS
>  and the complete Lund stuff (not an endorsement, just a mention).
>
>  HTH
>
>  Christian "loves to do perf stuff" Lheureux
>
>   >>
> Yes, we will be looking at this more carefully.  We have
> Glance and Lund's
> SOS.
> I posted this because it was such a shock.
>
> Cecile Chi
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2