On Wed, 18 Mar 2009 04:32:44 -0500, Big Iron <[email protected]> wrote:
>The storage report doesn't appear to indicate an issue. You may wish to >investigate performance issues with CEEVGTSI with IBM support. > >Bill > >On Wed, 18 Mar 2009 10:26:50 +0200, Arie Kremer <[email protected]> wrote: > >>Hi, >> >>Please see my question at the end of this mail... >> >>Our customer run strobe report and found that CEEVGTSI took 55% CPU: >> >>.LELIB CEEBINIT CEEVGTSI GET A STACK >>INCREMENT 54.55 54.55 54.55 54.55 >> .LELIB CEEBINIT CEEVOGTS XTND USR STK/DSA >>OPLINK 3.35 3.35 57.90 57.90 >> .LELIB CEEPLPKA CEEV#GH ALLOCATE >>STORAGE 2.37 2.41 60.27 60.31 >> .LELIB CEEPLPKA CEEV#FH FREE >>STORAGE 2.26 2.26 62.53 >>62.57 >> .LELIB CEEEV003 EDCVSPTF LE/370 C EVENT >>HANDLER 1.05 1.05 63.58 63.62 >> BASE @ST00038 >>000F50 2 .93 .93 64.51 64.55 >> BASE @ST00105 >>002B84 2 .82 .82 65.33 65.37 >> .LELIB CEEEV003 EDCMMOVE LE/370 C EVENT >>HANDLER .51 .51 65.84 65.88 >> .LELIB CEEBINIT CEEVGTS XTND USR STACK, GET >>DSA .47 .47 66.31 66.35 >> .COMSERV EZBTIINI EZBTCFWR >>TCP/IP .43 .43 >>66.74 66.78 >> >> >>CEEVGTSI is called from many places of our BASE module. The product uses >>multothread architechture, it receives TCP/IP requests and moves them to >>CICS via EXCI. >> >>ALL31(OFF) >> >>RPTSTG report: >>0 STACK statistics: >> Initial size: 2048000 >> Increment size: 1024000 >> Maximum used by all concurrent threads: 31584 >> Largest used by any thread: 31584 >> Number of segments allocated: 1 >> Number of segments freed: 0 >>0 THREADSTACK statistics: >> Initial size: 0 >> Increment size: 0 >> Maximum used by all concurrent threads: 0 >> Largest used by any thread: 0 >> Number of segments allocated: 0 >> Number of segments freed: 0 >>0 LIBSTACK statistics: >> Initial size: 32768 >> Increment size: 16384 >> Maximum used by all concurrent threads: 0 >> Largest used by any thread: 0 >> Number of segments allocated: 1 >> Number of segments freed: 0 >>0 THREADHEAP statistics: >> Initial size: 4096 >> Increment size: 4096 >> Maximum used by all concurrent threads: 0 >> Largest used by any thread: 0 >> Successful Get Heap requests: 0 >> Successful Free Heap requests: 0 >> Number of segments allocated: 0 >> Number of segments freed: 0 >>0 HEAP statistics: >> Initial size: 14336000 >> Increment size: 524288 >> Total heap storage used (sugg. initial size): 11751304 >> Successful Get Heap requests: 144269 >> Successful Free Heap requests: 144237 >> Number of segments allocated: 1 >> Number of segments freed: 0 >> >> >>My question is: may the large number of Get heap requests cause such >>problem? If not, what the problem may be? >> >>Arie Kremer >> The first thing to be sure to understand is that when RPTSTG(ON) is in effect, CEEVGTSI will get control all the time. What are the numbers for the CSECT usage when RPTSTG(ON) is not in effect? Also, what runtime options are in effect? Heavy usage of CEEVGTSI is almost always attributed to one or more of the following conditions: 1) RPTSTG(ON) being in effect, 2) runtime option STORAGE(,,xx) where xx is something other than NONE or CLEAR, and 3) when the application may be toggling over a stack segment boundary due to STACK(,,,FREE) being in effect. Nick Carbone IBM Language Environment ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
