Re: Strobe Analysis shows lots of Commonx

Peter [IBM GSA] Robinson

Re: Strobe Analysis shows lots of Commonx
(in response to Bill Happel)
Hi Brian

Jim's description reminds me of something we found a while back - I don't
recall exactly what was in our strobe results. We found that the mvs
overheads involved in managing external data with COBOL were large. Have a
look and see how much you use externals for passing data around.

PJR

Peter Robinson
Senior Performance DBA
Measurement & Performance
IBM-GSA Enterprise Services
Brisbane, Australia

* BG10, PO Box 435, Brisbane 4001
> ' (07) 3887-8129 or 0418-400-959
> 7 (07) 3221-0173
> * [login to unmask email]
[login to unmask email]


> -----Original Message-----
> From: Jim Lewandowski [SMTP:[login to unmask email]
> Sent: Wednesday, August 23, 2000 10:04 AM
> To: [login to unmask email]
> Subject: Re: Strobe Analysis shows lots of Commonx
>
> I assume COMMONX is extended ECSA (31-bit common storage addressable by
> all address spaces) - it's a while since I perused a STROBE report.
>
> No, this is basically MVS/OS390-like nucleus code that is being called
> indirectly on behalf of MVS providing the user/program-requested
> service/function. Like a byproduct of MVS managing your working set
> (4K pages needed in central to allow your program to run), paging on
> behalf of your program's storage requirements, that type of stuff.
>
> However, if you can get the module name(s) itself accounting for this
> COMMONX CPU usage, you MIGHT (though not probable) find you can modify
> the application program to reduce these system/service calls.
>
> Jim Lewandowski
>
>
> [login to unmask email] wrote:
> >
> > While performance-testing a large batch cobol db2 application on a test
> LPAR,
> > I've noticed
> > that a large proportion of the CPU cost is allocated by Strobe to
> .COMMONX (in
> > the
> > example below it's 22.43%). Can anybody tell me if it's possible to
> tweak this,
> > and if so,
> > how? Can I do something in the application, or do I need to look at
> things like
> > dispatching
> > priorities, whether its been swapped out a lot etc.?
> >
> > .COMMON .COMMONX EXTENDED COMMON AREA
> > 22.43 22.43 22.43 22.43
> > .DB2 DSNBBM DSNB1GET RETRIEVE REQUESTED PAGE
> > 3.10 3.10 25.53 25.53
> > .NUCLEUS IEAVSTA1 COMM TASK ESTAE
> > 3.03 3.03 28.56 28.56
> > .DB2 DSNXGRDS DSNXERD TOPMOST RDS CSECT
> > 3.00 3.00 31.56 31.56
> > .NUCLEUS IEAVRT05 TIMER SERVICE
> > 2.51 2.51 34.07 34.07
> > .DB2 DSNXGRDS DSNXVPC2 COM CONV RTN NON-NUMER
> > 2.50 2.50 36.57 36.57
> > .DB2 DSN3EPX DB2 SYSTEM SERVICES
> > 2.42 2.42 38.99 38.99
> > .DB2 DSNXGRDS DSNXROUA RUN-TIME RET VALUES EXEC
> > 2.41 2.42 41.40 41.41
> > .DB2 DSNXGRDS DSNXERT APPLICATION CALL ROUTINE
> > 2.40 2.40 43.80 43.81
> > .DB2 DSNWVCOL SELECTIVE TRACE REC COLL
> > 2.22
> >
> > thanks in advance,
> > Brian
> >
> >
> >
> the DB2-L webpage at http://www.ryci.com/db2-l The owners of the
> list can be reached a
>
>
>
>
>



Bill Happel

Strobe Analysis shows lots of Commonx ( -OOO Reply)
I will be at Out Of the Office from Wednesday, August 23nd to Thursady afternoon, August 24th. I will be back in the office on Thursday afternoon, August 24th. Please call the DBA Hotline at x5582.

>>> "[login to unmask email]" 08/22/00 18:04 >>>

I assume COMMONX is extended ECSA (31-bit common storage addressable by
all address spaces) - it's a while since I perused a STROBE report.

No, this is basically MVS/OS390-like nucleus code that is being called
indirectly on behalf of MVS providing the user/program-requested
service/function. Like a byproduct of MVS managing your working set
(4K pages needed in central to allow your program to run), paging on
behalf of your program's storage requirements, that type of stuff.

However, if you can get the module name(s) itself accounting for this
COMMONX CPU usage, you MIGHT (though not probable) find you can modify
the application program to reduce these system/service calls.

Jim Lewandowski


[login to unmask email] wrote:
>
> While performance-testing a large batch cobol db2 application on a test LPAR,
> I've noticed
> that a large proportion of the CPU cost is allocated by Strobe to .COMMONX (in
> the
> example below it's 22.43%). Can anybody tell me if it's possible to tweak this,
> and if so,
> how? Can I do something in the application, or do I need to look at things like
> dispatching
> priorities, whether its been swapped out a lot etc.?
>
> .COMMON .COMMONX EXTENDED COMMON AREA
> 22.43 22.43 22.43 22.43
> .DB2 DSNBBM DSNB1GET RETRIEVE REQUESTED PAGE
> 3.10 3.10 25.53 25.53
> .NUCLEUS IEAVSTA1 COMM TASK ESTAE
> 3.03 3.03 28.56 28.56
> .DB2 DSNXGRDS DSNXERD TOPMOST RDS CSECT
> 3.00 3.00 31.56 31.56
> .NUCLEUS IEAVRT05 TIMER SERVICE
> 2.51 2.51 34.07 34.07
> .DB2 DSNXGRDS DSNXVPC2 COM CONV RTN NON-NUMER
> 2.50 2.50 36.57 36.57
> .DB2 DSN3EPX DB2 SYSTEM SERVICES
> 2.42 2.42 38.99 38.99
> .DB2 DSNXGRDS DSNXROUA RUN-TIME RET VALUES EXEC
> 2.41 2.42 41.40 41.41
> .DB2 DSNXGRDS DSNXERT APPLICATION CALL ROUTINE
> 2.40 2.40 43.80 43.81
> .DB2 DSNWVCOL SELECTIVE TRACE REC COLL
> 2.22
>
> thanks in advance,
> Brian
>
>
> visit the DB2-L webpage at http://www.ryci.com/db2-l The owners of the
list can be reached a




****************************************************************
Please Note
The information in this E-mail message is legally privileged
and confidential information intended only for the use of the
individual(s) named above. If you, the reader of this message,
are not the intended recipient, you are hereby notified that
you should not further disseminate, distribute, or forward this
E-mail message. If you have received this E-mail in error,
please notify the sender. Thank you
*****************************************************************



Mark Labby

Re: Strobe Analysis shows lots of Commonx
(in response to Peter [IBM GSA] Robinson)
Check and see if you have which monitoring tools you may have running, it
may not actually be the application itself that is using the CPU.

We had the same results when looking at Strobe results of our big batch
jobs a few years ago. After digging into things for a while, everything we
saw pointed to PTXMAN that was being run to collect statistics for the
Platinum Detector and SubSystem Analyzer. In some cases, we saw in excess
of 30% of the CPU being attributed to Commonx during very large batch jobs
with PTXMAN running.

Of course Platinum said that their tool would only add about 2% to the
load, but after talking to enough people they did say that was based on a
general mix of on-line and batch jobs running. The overhead goes up
significantly when in very CPU and I/O intensive batch mode like we are at
night. Needless to say, this was all our management needed to hear and now
it is verboten for us to leave the monitor running overnight. (Kinda
defeats the purpose in having them, huh?)






[login to unmask email]@RYCI.COM> on 08/22/2000 03:24:39 PM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

Sent by: DB2 Data Base Discussion List <[login to unmask email]>


To: [login to unmask email]
cc:

Subject: Strobe Analysis shows lots of Commonx


While performance-testing a large batch cobol db2 application on a test
LPAR,
I've noticed
that a large proportion of the CPU cost is allocated by Strobe to .COMMONX
(in
the
example below it's 22.43%). Can anybody tell me if it's possible to tweak
this,
and if so,
how? Can I do something in the application, or do I need to look at things
like
dispatching
priorities, whether its been swapped out a lot etc.?


.COMMON .COMMONX EXTENDED COMMON AREA
22.43 22.43 22.43 22.43
.DB2 DSNBBM DSNB1GET RETRIEVE REQUESTED PAGE
3.10 3.10 25.53 25.53
.NUCLEUS IEAVSTA1 COMM TASK ESTAE
3.03 3.03 28.56 28.56
.DB2 DSNXGRDS DSNXERD TOPMOST RDS CSECT
3.00 3.00 31.56 31.56
.NUCLEUS IEAVRT05 TIMER SERVICE
2.51 2.51 34.07 34.07
.DB2 DSNXGRDS DSNXVPC2 COM CONV RTN NON-NUMER
2.50 2.50 36.57 36.57
.DB2 DSN3EPX DB2 SYSTEM SERVICES
2.42 2.42 38.99 38.99
.DB2 DSNXGRDS DSNXROUA RUN-TIME RET VALUES EXEC
2.41 2.42 41.40 41.41
.DB2 DSNXGRDS DSNXERT APPLICATION CALL ROUTINE
2.40 2.40 43.80 43.81
.DB2 DSNWVCOL SELECTIVE TRACE REC COLL
2.22


thanks in advance,
Brian








Jim Lewandowski

Re: Strobe Analysis shows lots of Commonx
(in response to Mark Labby)
Robinson, Peter [IBM GSA] wrote:
>
> Hi Brian
>
> Jim's description reminds me of something we found a while back - I don't
> recall exactly what was in our strobe results. We found that the mvs
> overheads involved in managing external data with COBOL were large. Have a
> look and see how much you use externals for passing data around.


No. The Cobol runtime modules (ILB, IGZ) will not be in COMMONX
(ECSA) since they are loaded into the local address spaces private area
(Subpool 0) at run time. COMMONX stuff is MVS-related only that was put
there at IPL time.

Jim Lewandowski