< Update from HP ... >
I (HP) have been working closely with the lab, the stack trace you see
is normal. KSAM/XL (and ksam64) has to protect the key area of the file
even if you are just reading. This is how xm and ksam works. This is
not a bug it's by design.
You don't see this with a flat file, a flat file attached to XM or with
a CM KSAM file or even TurboImage. These files do not guard themselves
from user applications in the same way as KSAM/XL (and ksam64). .
That's also why you see better performance with concurrent reads of
these kinds of files, you benefit from having more accessors ensuring
enough of the file is in memory to get decent performance.
To take xm out of the equation, you could use KSAM CM.
< ... End of HP's update - >
< now for my comment ! >
Thus, the current recommendation is to avoid NM Ksam as this can put XM
under severe stress especially on multi-CPU servers !
I'm posting this update to HP3000-L as this could be a problem for all
TPI vendors of Image/Allbase.
I'm still querying with HP as to why XM has to be involved in a NM ksam
read; especially as we followed the recommended procedures in the KSAM
manuals to cater for the fact that these files are shared access (we
call FLOCK and FUNLOCK in an intelligent manner inside our database
handler).
The fact that the problem is related to XM explains why the performance
problems escalate to all processes on the server that are accessing KSAM
files, regardless of whether the process is accessing files in the
development or production accounts.
HP are now looking at our user volumes and the performance of our XM -
I'm guessing their recommendation will be to increase the number of user
volumes and thus increase the number of XM processes.
As for their suggestion of reverting to CM KSAM, there are several
problems I can think of ... I'm sure you can think of more...
1) we lose XM protection (the reason we went to NM ksam)
2) high levels of CM switching ...
3) resulting in CM ksam using more CPU than NM Ksam (proved by
experiments at the weekend)
4) The CM Keyfile uses more disc space (NM ksam files grow on demand)
5) After a system crash, KSAMUTIL has to be used to verify the file
before it can be accessed
-----Original Message-----
From: Tony Summers
Sent: 28 April 2006 12:21
To: [log in to unmask]
Subject: Update on our performance problems (KSAM related)
This is a brief note to update everyone with our on-going performance
problems. Thanks for everyone who has helped with suggestions so far.
As a reminder, we were getting complaints from our production users that
the system was occasionally running really slowly, and over the last few
months we put some quick patches in place to ensure that certain
programs would only run overnight and we improved the performance of a
few intra-day problems. We also added more memory.
When there are performance problems, then Glance reports a high number
of impedes on the system.
We were hoping that our Easter system maintenance (rebuilding all our
files and defragging the file system) would have eliminated the
problems. Alas, the performance problems did not go away although there
was some improvement in our overnight batch processing.
We HAD been thinking that our database handler and a third party
vendor's ODBC driver were both issuing a high number of FLOCKS against
our KSAM database which was resulting in each process naturally impeding
until the FLOCK was cancelled. You will have seen my previous posts
asking how to identify the flocks.
However, in the run up to the Easter weekend, I was found (by accident)
a combination of our standard production applications that reproduce the
performance problems on demand. Since Easter, by a slow process of
elimination and by writing a series of test programs, it would appear
that the impede problems are caused by the following set of
circumstances all happening at once
1) the problem only occurs on our 4-cpu server, not on our DR server
which is a single CPU server
2) the problem only occurs on NM KSAM files (and KSAM64 files), it
does not occur on CM Ksam nor on plain vanilla mpe files. I cannot
comment on image as we don't use it !
3) the problem only occurs when there are 4 or more processes
concurrently issuing lots of FREAD intrinsics against our KSAM files.
My tests have more or less dismissed Memory, DISC or CPU, network issues
as the reason for the impedes. Flocks in the database handler are a
very minor factor but my test applications are no longer using Flocks at
all.
My experiments are on-going to isolate any other conditions that point
to the underlying cause.
HP have been providing lots of helpful advice and our investigations
with them continue. (I've blind copied all relevant parties into this
email).
The current theory from HP is that transaction manager (XM) is somehow
causing a problem, but my understanding of XM is that it only gets
involved in update activity. It would explain why CM KSAM isn't
affected. Maybe XM has to be referenced en route to the successful
execution of an FREAD.
From my perspective, (but I would love to be proved wrong) the
simultaneous execution of 4 or more FREADs against NM Ksam on our 4-cpu
server is somehow being constrained by an internal resource deep in the
heart of MPE - almost as if the NM KSAM sub-system is simply unable to
take advantage of our 4 cpus. We'll continue to try and identify the
underlying cause, and I have some experiments to run this weekend on
behalf of HP. HP are also booked to dial into the system and observe
the problems directly. Their experienced eye may spot the problem
straight away.
No reply needed to this email other than to wish us luck !
For our in-depth analysis of the budget, visit our website at www.smith.williamson.co.uk
The contents of this email are confidential to the intended recipient
and may not be disclosed. Although it is believed that this email and
any attachments are virus free, it is the responsibility of the recipient to confirm this.
Smith & Williamson Corporate Finance Limited - A member of the London Stock Exchange.
A member of M&A International Inc. http://www.mergers.net Registered in England No. 4533970. Authorised and regulated by the Financial Services Authority
Smith & Williamson Investment Management Limited, Registered No. 976145. Authorised and regulated by the Financial Services Authority.
Smith & Williamson Pension Consultancy Limited - Independent Intermediary. Registered No. 3133226. Authorised and regulated by the Financial Services Authority.
Smith & Williamson Fund Administration Limited, Registered No. 1934644. Authorised and regulated by the Financial Services Authority.
Smith & Williamson Limited - A member of Nexia International. Registered in England No. 4534022. Regulated by the Institute of Chartered Accountants in England & Wales for a range of investment business activities.
NCL Investments Limited, Registered No. 1913794.
Member of the London Stock Exchange authorised and regulated by the Financial Services Authority.
Registered Office: 25 Moorgate, London EC2R 6AY
Telephone: 020 7131 4000 http://www.smith.williamson.co.uk
Nexia Smith & Williamson Audit Limited - A member of Nexia International. Registered in England No. 4469576.
Nexia Smith & Williamson Audit Limited is a company registered to carry out audit work and is regulated for a range of investment activities by the Institute of Chartered Accountants in England and Wales. Smith & Williamson Limited is a separate company that provides professional resources and certain services to Nexia Smith & Williamson Audit Limited under the terms of a formal agreement on an arm+IBk-s length basis.
Registered Office: 25 Moorgate, London EC2R 6AY
Telephone: 020 7131 4000 http://www.nexiasmith.williamson.co.uk
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
