II can't speak too much to the excp counts, but re: CPU usage. Unix systems "count the beans" very differently than z/OS. The "system overhead" (uncaptured CPU time) for z/OS averages about 10%. The Unix systems I have encountered routinely exceed 40%.
Perhaps looking at a unix process through a z/OS lens (RMF global data capture) is distorting things? I would also check the region size allocated to the ZCX address space. Paging might be masquerading as IO due to the z/OS lens being used. HTH, -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Sean Gleann Sent: Wednesday, August 26, 2020 3:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ZCX task monitoring, anyone? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Can anyone offer advice, please, with regard to monitoring the system resource consumption of a zcx Container task? I've got a zcx Container task running on a 'sandbox' system where - as yet - I'm not collecting any RMF/SMF data. Because of that, my only source of system usage is the SDSF DA panel. I feel that the numbers I see there are... 'questionable' is the best word I can think of. Firstly, the EXCP-count for the task goes up to about 15360 during the initial start-up phase, but then it stays there until the STOP command is issued. At that point, EXCP-count starts rising again, until the task finally terminates. The explanation for that is probably because all the I/O is being handled internally at the 'Linux' level - the task must be doing *some* I/O, right? - but the data isn't getting back to SDSF for some reason. Without the benefit of SMF data to examine, I'm wondering if this is part of a larger problem. The other thing that troubles me is the CPU% busy value. My sandbox system has 5 engines defined, and in the 'start.json' file that controls the zcx Container task, I've specified a 'cpu' value of 4. During the start-up phase for the Container started task, SDSF shows CPU% values of approx 80%, but when the task is finally initialised, this drops to 'tickover' rates of about 1%. I'm happy with that - the initial start-up of *any* task as complex as a zcx Container is likely to cause high CPU usage, and the subsequent drop to the 1% levels is fine by me. But... Once the Container task is started and I've ssh'd into it, I then want to monitor its 'internal' system consumption. I've been using the 'Getting Started...' redbook as my guide throughout all this project, and it talks about using "Nodeexporter", "Cadvisor", "Prometheus" and "Grafana" as tools for this. I've got all those things installed and I can start and stop them quite happily, but I've found that using Cadvisor on it's own can drive CPU% levels back up to 80% for the entire time it is running. If a system is running flat-out when all it is doing is monitoring itself, well, there's something wrong somewhere... I'm trying to find an idiot's guide to controlling what Cadvisor does, but as yet I've been unsuccessful. Regards Sean ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
