"Barbara Nitz" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Kees, > > >- Is the WLM PI number the real problem, or is the performance actually > >bad? A bad report about a well running application is not the end of the > >world. > We started looking at this when we had complaints about missing throughput and bad response times. Before that, we didn't even realize how bad the PI was. > > >- If they all pop up at about the same time, how would you like to see a > >2 CP Lpar handle 65 tasks at (about) the same moment??? WLM or no WLM, > >here you have a real problem I think, even if the Lpar Weight were high > >enough. > Exactly my point: I think *someone* needs to take a real hard look at how this product was ported to z/OS. (I didn't mention that it was ported from the 'open world', did I?) I also think to 'play nice' in a z/OS world, it needs design changes, one of them being the use of WLM macros to actually define the start and the end of a transaction, just so I can use a response time goal. :-) > In addition, there need to be much better guidelines on how to tune this application with the obvious things - like storage usage in LE, like what effect committing messages has (there were also lots of SSRBs - suspended somewhere in RRS/LOGR processing) and how often to do that. I am sure my 1.5s trace table only scratches the surface. Besides, a trace table is not the right tool to look at a problem like this. > > >did you define them as CPU CRITICAL? > No. On the assumption that I can *see* that the DP of these 65 things is definitely higher than anything else on that lpar (aside from sysstc and the obvious supporters). Also, giving it one more processor didn't help the PI. Should I test that, anyway? > > My biggest concern with the high PI is actually that WLM will only try to help the service class every 3rd trip through WLM (so I was told). WLM doesn't look at it for two intervals. And the intervals are long, anyway (10s?). The WLM developer basically told me that it doesn't matter that WLM will not help the class for that long. This is what really go my hackles up, we just don't have a continuous workload, we have extreme spikes and are supposed to have good response times even in spike situations. > In order to achieve a continuous help for this class, I have to set the velocity artificially to 1% or less, just to influence the computing, if I can even define it that low. That probably gets me a whole lot of other problems. > I have also been told (completely differnt guy in WLM) that it is necessary to define a resource group with a very high guaranteed minimum consumption whenever I go below 30% for an exvel goal. So far I have managed to avoid that by basically only using the importance for classification and the exvel always being 31 or higher. Which doesn't give me much room until I hit the 'unachievable goal'. (Oh, I *was* told that Imp1, exvel 40% is too ambitious!) > > Does that make my dilemma clearer? > > Best regards and thanks, Barbara
Yes, the picture becomes clear. I still have 3 thoughts: - How did this thing run in the 'open' world (or didn't it)? Machines with dozens of processors to execute these 65 tasks immediately are not common there either AFAIK. - I am a little worried about your remark about the (short) life of the address spaces: creating a new thread in Unix is just simply adding an entry to a process table; if it requires address space creation in z/OS, this is a heavy overhead part added to kicking off the task. Can you play around with BPXPRM parameters to keep these address spaces (BPXAS I suppose) alive for a longer period, so they can be reused? - If the DP's are well positioned between the Sysstc (MQ etc.) and the low prio other stuff, what exactly do you expect from WLM? WLM can in fact only influence performance of tasks by manipulating their relative DP's. If they are positioned well, it is up to the Dispatcher to dispatch them on the available CP's. What can WLM stil do in this situation? Regards, Kees. ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************************** ---------------------------------------------------------------------- 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
