URG: --MSTR address space pegging CPU

Venkat Srinivasan

URG: --MSTR address space pegging CPU
Esteemed Listers,

A client of mine is in DB2 V 8 compat mode on GA release except for a PTF
addressing SORT performance during utility processing.

The client went live with the application (PeopleSoft CRM)yesterday and
since then they are witnessing a progressive higher CPU utilization on
MSTR address space.
It started at 9% and gradually climbed upto 23% now. Even when no thread
is active the CPU utilization continuously grows.
While all this is happening, DBM1 CPU util is way less. (less thaqn 5% on
an average) and so is DIST.

This is not an update intensive application. There is no other symptom /
errors in syslog or mstr itself. MSTR just keeps churning cycles.

We are also in touch with level 2 but so far we have not got any
conclusive pointers. No apparent cause / reason is visible in MSTR/DBM1
DUMP.

Anyone else has ever encountered such a situation?

Regards,
Venkat

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Joel Goldstein

Re: URG: --MSTR address space pegging CPU
(in response to Venkat Srinivasan)
The only time I ever saw MSTR peg a CPU was during a big backout.
Not saying this is the case now. If it's churning I/O too, then this is not
it.

Regards,
Joel

----- Original Message -----
From: "Venkat Srinivasan" <[login to unmask email]>
Newsgroups: bit.listserv.db2-l
To: <[login to unmask email]>
Sent: Tuesday, January 11, 2005 10:33 PM
Subject: [DB2-L] URG: --MSTR address space pegging CPU


> Esteemed Listers,
>
> A client of mine is in DB2 V 8 compat mode on GA release except for a PTF
> addressing SORT performance during utility processing.
>
> The client went live with the application (PeopleSoft CRM)yesterday and
> since then they are witnessing a progressive higher CPU utilization on
> MSTR address space.
> It started at 9% and gradually climbed upto 23% now. Even when no thread
> is active the CPU utilization continuously grows.
> While all this is happening, DBM1 CPU util is way less. (less thaqn 5% on
> an average) and so is DIST.
>
> This is not an update intensive application. There is no other symptom /
> errors in syslog or mstr itself. MSTR just keeps churning cycles.
>
> We are also in touch with level 2 but so far we have not got any
> conclusive pointers. No apparent cause / reason is visible in MSTR/DBM1
> DUMP.
>
> Anyone else has ever encountered such a situation?
>
> Regards,
> Venkat
>
> ---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
> home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
> select "Join or Leave the list". The IDUG DB2-L FAQ is at
> http://www.idugdb2-l.org. The IDUG List Admins can be reached at
> [login to unmask email] Find out the latest on IDUG conferences
> at http://conferences.idug.org/index.cfm
>
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Venkat Srinivasan

Re: URG: --MSTR address space pegging CPU
(in response to Joel Goldstein)
Joel,
There is no backout process either intentional or due to abnormal end of
task.
What is interesting is the fact that the CPU util just keeps climbing over
time.
Level 2 gave some counseling on a similar behavior on DBM1 but nothing
addressing MSTR.
We are taking down DB2 in a while to recycle the subsystem hoping it would
provide a temporary remedy.

Regards,
Venkat

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Richard Humphris

Re: URG: --MSTR address space pegging CPU
(in response to Venkat Srinivasan)
I believe this will be off the subject... And yet... DB2MSTR does most
of the WTO's for DB2. And this got me to thinking about a perverse way
of how DB2 could be hurt by console automation and how console
automation may/might? be able to charge it's cpu to DB2MSTR.

I know that OPS/MVS (and probably any other automated operator type
products) can introduce performance problems with poorly coded MSG type
rules. This is because the message rule effectively becomes a
subroutine to the WTO itself. So if a message rule were to "wait 10
seconds" (a really bad idea and one OPS/MVS takes measures to try and
prevent this) then the task (tcb/srb) would have to wait that 10 seconds
for the WTO to complete!!!

However, if the message rule didn't "wait" 10 seconds but actually
consumes 10 seconds of CPU time (and elapsed time) then ops/mvs wouldn't
normally prevent that... But to whom would the cpu be charged to... the
issuer of the WTO (DB2MSTR) or to the console automation product???
Note: I assume that DB2MSTR wouldn't use the TCB to issue the WTO's, so
only a SRB would have to wait for the WTO to complete instead of the
entire address space.

Rich Humphris

P.s. I know I'm picking on OPS/MVS but I believe all console automation
products work the same way by initially intercepting wto's. Note too:
a message rule in ops can start a request rule and if the msg rule then
exits, the wto will immediatedly complete. Request rules were created
by OPS/MVS to allow explicit coded waits, etc. to be coded without
having any performance problems as they run asynchronously in separate
Ops/mvs address spaces which are not associated with
intercepting/delaying WTO messages.

P.s. If you are running multiple console automation products then the
WTO will have to wait on each product which directly intercepts the
message. This is because a console automation product(s) can redirect a
message to different consoles, change the message text (if it wants),
change attributes, etc. before the wto is actually sent to the system.
This is why when ops/mvs wants to issue a command when a certain message
appears (for example) it will look, in syslog, that ops/mvs issued the
command RIGHT BEFORE the message appeared. That's because the message
rule intercepts the message, issued the command which updates syslog,
but the original wto can't actually be written until after the ops/mvs
message rule completes; and so, in syslog the two events appear "out of
sequence".

E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the
addressee(s) and may contain confidential and/or legally privileged information. If you are not the
intended recipient of this message or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this message and any attachments. If you
are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or
storage of this message or any attachment is strictly prohibited.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Richard Humphris

Re: URG: --MSTR address space pegging CPU
(in response to Richard Humphris)
Btw, to continue talking about console automation, this is why a message
rule which traps every message on the system can be nasty... And if such
a rule is needed, it should try to exit as soon as possible for messages
it decides it really didn't have to process.

Note: a single message can be processed by multiple message rules under
OPS/MVS if it meets the message selection criteria.

Rich Humphris

E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the
addressee(s) and may contain confidential and/or legally privileged information. If you are not the
intended recipient of this message or if this message has been addressed to you in error, please
immediately alert the sender by reply e-mail and then delete this message and any attachments. If you
are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or
storage of this message or any attachment is strictly prohibited.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm