Thank you Brian,
A long time ago, on a machine long gone, when we last had capacity problems,
one of the issues was velocities set higher than the machine could attain,
resulting in PI such that WLM pretty much gave up.
At that time, I think on the list here, I was helped to set more realistic
velocity goals. This and several other tweaks, and I eventually had a pretty
well tuned policy for the then z800-0B1. In 2007, we approximately tripled
our capacity with a z9-L03. I have only needed to make minor changes to the
policy since, the last in 2016.
We ran on that z9 for 10 years, softcapped at 16 MSU for most of that time.
December 2017, we moved to MFaaS on a z114 and now the z13
We are trying to reduce our cost as we wind down. Recently we dropped the
softcap from 15 to 12. And, I did one last upgrade to z/OS 2.3
I run 4 LPARs at the moment, weighted. Prod (11), Devl(3) Sand1(1) Sand2(1).
The pain is only minor in Prod, some increase elapsed time in batch,
occasional sluggish TSO. The Adabas, CICS and Broker seem pretty good, not sure
about Connx, and really wonder about the new webserver with 2.3.
The main issue is inconsistent failures of batch FTP probably during high
batch processing extracting the data to ftp. And then slow TSO when they try to
resolve the issue.
When I looked today, I found a lot of ancient debris in my 14 year old
policy. RMF III did show Adabas achieving 87, but I recalled the time when I
set the goals down to where they are now. So, I asked.
My plan is to clean the debris out, and see just where I had FTP set. I
think it's in my 3 tiered TSO workload, which could have it undesirably
dropping into discretionary
Thanks for your advice. It has given me more to think on. I need to dig out
my old tools in this area. It truly has been near decades since I needed them
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On
> Behalf Of Brian Westerman
> Sent: Tuesday, October 13, 2020 10:10 PM
> To: [email protected]
> Subject: Re: Max possible velocity?
>
> Hi Dave,
>
> It's very difficult to tell you where the bottlenecks are when I can't see the
> values for myself, but generally, you can get away with some things in a lake
> than you can in a swimming pool. The velocities are all relative, so 90 is
> still
> 90, just like if you were using the old IPS/ICS, where you were dealing in
> dispatching priorities, the numbers are meaningful relative to themselves.
> As long as the system doesn't still "think" it has 20% more than it actually
> does (i.e. still thinks it has 15) :)
>
> When you downgraded, did you have (and do you still have) any specialty
> processors? They continue to run full speed even after the downgrade.
> Since you have a 5-way, is it possible that not every one of the processors
> was downgraded equally? I'm pretty sure you can check it in RMF to be sure.
> One of our clients had a 6 way z13 that was downgraded and there was an
> error that resulted in 4 REALLY slow processors and 2 (much) faster ones.
> Luckily it was an error we discovered in the benchmarking, but IBM had
> already left for the day. (we called them back in:)) Strangely enough, we
> didn't discover the error until multiple really heavily loaded tests were
> started.
>
> Assuming IBM got better at the process by now, but you never know.
> Anyway, if Adabas is at 90/1 and I assume that your com-plete (or CICS)
> follows closely behind (Maybe 85 or 80/1?), and any brokers and/or natural
> servers are (at least) higher than production and/or normal batch, and of
> course your TSO users are also lower than the SAG stuff, then things should
> be okay. It also could be something simple like you have things losing the
> thread before they were ready and you end up re-doing a lot of work when
> they come back in.
>
> Is the slowdown apparent in just the on-lines or is it noticeable across the
> whole system? Does batch also seem to be affected (i.e. you dropped 20%
> of the system, but how badly was batch affected? You can compare some
> jobs from before and after the downgrade that are fairly constant to tell.
> Your weekly Adabas backups would be a good indicator of the batch
> processing effects. The way to "fix" things could be wildly different if
> depending on who is affected and how. It could be that you had REALLY BIG
> buffers defined for Adabas and when you had a lot of extra capacity it didn't
> matter, but maybe now it's spending more time shuffling things around and
> reading really far ahead for tasks that just won't be able to take advantage
> of
> it, so more busywork ends up happening than actually productive work.
> Again, it's really hard to tell without more information.
>
> Sometimes what happens is that people keep running SQL queries and
> pound the system just as hard as they would when you had the capacity to
> spare. Maybe they didn't get the word that they have 20% less to work with.
> It helps if you can limit them by splitting them away from the normal "good
> guy" regular Joe users.
>
> Can you tell who the big users are that are getting you? Do you run REVIEW
> or TRIM so that you can see who is causing the (most) overhead?
>
> If you want to contact me offline, please feel free to do so. I'll try to
> help you
> all I can.
>
> Brian
>
>
> On Tue, 13 Oct 2020 21:27:30 +0000, Gibney, Dave <[email protected]>
> wrote:
>
> >It has been quite some time since I had to worry about my WLM policy.
> We've had ample capacity since 2007. Now, as We begin to wind down, we
> have reduced our contracted MSU capacity.
> >We dropped from 15 to 12 on an 5 way z13S-N05. My WLM policy, last
> seriously adjusted in 2007 when we moved to a z9-L03 has velocities ranging
> from a high of 90 (Adabas, Imp 1) down to 5 (BATCH Imp 5)
> >We are experiencing just a minor amount of performance pain. It strikes me
> that perhaps some of my higher velocity goals (90, 70, 60, 50) may be
> unattainable under the now reduced capacity.
> >
> >What is the high end for possible, single threaded (Adabas) velocity here?
> Or, where should I be reading in current manuals. I was better at this 15
> years
> ago.
> >
> >Dave Gibney
> >Information Technology Services
> >Washington State University
> >
> >
> >----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
