The only big performance hit I'm aware of on 7.x is when reading and writing
to flat files which you indicate that this job does. I was told to expect
20-40% hit if your batch job deals exclusively with flat files and has a
high I/O rate. This is because HP had to add decision branches to the file
access code to determine if you are dealing with an old file type or one of
the new file types introduced in 7.0.
But what you are seeing does sound a lot worse than what I was told to
expect. Have you talked to the RC about this?
Carl McNamee
Systems Manager
Billing Concepts
(210) 949-7282
-----Original Message-----
From: Cecile Chi [mailto:[log in to unmask]]
Sent: Tuesday, November 20, 2001 6:46 AM
To: [log in to unmask]
Subject: 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 *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
