|
View previous topic :: View next topic
|
| Author |
Message |
vicky10001
Warnings : 1
Active User
.jpg)
Joined: 13 Jul 2005
Posts: 136
|
|
|
|
Dear All,
We are tuning the TCPIP job in mainframe. It was consuming huge Mips. TCPIP has turned ON the below trace. We need to know the advantages/disadvantages of below traces. How much % CPU overhead for each trace. We can trun off this traces if its not useful. Could you please let us know your thoughts on this.
NTATRCSERVICE - This service enables network management applications to access trace data that is collected for all OSAENTA traces.
PKTTRCSERVICE - This service enables network management applications to access trace data collected for any active packet traces or data traces. Access control should be provided for this service
TCPCONNSERVICE -The service runs as a subtask in the TCP/IP stack address space. This service provides an interface for network management applications to obtain information about TCP connections on this stack.
SMFSERVICE - The service runs as a subtask in the TCP/IP stack address space. This service provides an interface for network management applications to obtain stack information in the form of SMF 119 records. This parameter can also be used, with or without subparameters, to request the creation of specific SMF 119 records which are then provided to applications that are connected to this service. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
My first question is, why use ANY traces unless you have a connectivity problem?
| Quote: |
| It was consuming huge Mips. |
Actually, no it is not. The TCP/IP started task might be consuming large amounts of CPU time, but CPU time is not MIPS and MIPS is not CPU time. Furthermore, MIPS is a term that is -- AT LEAST -- 10 years out of date (IBM uses MSU instead), and MIPS (even should it be used) cannot ever be applied to anything smaller than an LPAR -- never to an individual job or started task. Jobs and started tasks use CPU time, EXCPs, and other system resources -- but MIPS is a term that applies only to the entire machine (be that an LPAR or all the LPARs on the box), and there is solid reason not to use the term MIPS for an LPAR, even - -just the entire box.
And what does the term "huge" mean? Does that mean 60 seconds of CPU time in a day? 3600 seconds? 84400 seconds? If you're going to pretend to do performance tuning, at least use quantities instead of fuzzy terms like "huge"! |
|
| Back to top |
|
|
vicky10001
Warnings : 1
Active User
Joined: 13 Jul 2005
Posts: 136
|
|
|
|
| TCPIP job is consuming 60000 CPU Sec per day for our shop. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Turn off the traces. Check the parameters to see what is configured wrong, and maybe even get an IBM PMR open to get help. TCP/IP shouldn't be using more than a few percent of your machine. |
|
| Back to top |
|
|
vicky10001
Warnings : 1
Active User
Joined: 13 Jul 2005
Posts: 136
|
|
|
|
| We can't turn off the tracess without valid savings or reasons. We need to understand what for each trace and how much we can save if turn off the trace. Could you please let me know if you have any idea on this. thanks |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
| 60000 CPU Sec per day |
60000 sec = 1000 minutes = 16.666 hours
general question: how many CPU hours / day can a computer have? |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL
|
|
|
|
| vicky10001 wrote: |
| We can't turn off the tracess without valid savings or reasons. |
Did not Mr. Sample give a valid reason when he asked:
| Quote: |
| My first question is, why use ANY traces unless you have a connectivity problem? |
|
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Let me ask questions:
- how many TCP/IP traces does your site run each day?
- how many terminal sessions does your TCP/IP support a day?
- how many FTP sessions does your TCP/IP support a day?
- how many SMTP transmissions does your TCP/IP support a day?
- is your site using DNS on the mainframe or via a DNS server?
- how many translate tables does your site have set up for TCP/IP?
- does your site use a monitor such as Omegamon or Mainview that can pinpoint the high PCU cause?
Just to give you a basaline: our TCP/IP started task has been running since July 2011 (managers decided to stop the regular IPL since users wanted the system 24/7) with total CPU SRB time of 101,000 seconds and TCB time of 21,000 seconds -- for over 11 months of use. So I suspect one or more TCP/IP parameters are badly mis-coded at your site. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| general question: how many CPU hours / day can a computer have? |
When you've got 64 processors in your box, you'd be surprised at how many CPU hours per day there are ....  |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| thx, never bothered to think about the cpu time to number of processors. |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
| vicky10001 wrote: |
| We can't turn off the tracess without valid savings or reasons. We need to understand what for each trace and how much we can save if turn off the trace. Could you please let me know if you have any idea on this. thanks |
Um, yeah... here's an idea: TURN OFF THE TRACE AND SEE HOW MUCH IT SAVES!!
OR
Start an unused TCPIP stack with and without tracing to see if it makes any difference, then you've got the justification. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| We can't turn off the tracess without valid savings or reasons. We need to understand what for each trace and how much we can save if turn off the trace. |
Sounds like there is a grey-matter problem with whoever is "in charge". . . This kind of "people thing" can be far tougher to deal with than technical issues.
Why were all of these ever turned on? What validated the "need" to do so? Has anyone gotten much of value from them being turned on?
The conputer center probably really enjoys all of the extra/wasted resource they can charge for. . . |
|
| Back to top |
|
|
|
|
