Re: Storage pools and QHTTPSVR and QUSRWRK subsystems

I've been hesitating but here goes ...

On 06/02/2009, at 3:40 PM, Tom Liotta wrote:

Having them in a shared pool is one part. Another part is getting
everything else out of *BASE.

Yes, good practice.

In case anyone else wants to help add thoughts, I'll spill out my
understanding of some of this.

My understanding is that the performance adjuster doesn't move
memory from a shared pool that no longer needs it to one that does
need it. Rather, memory is always moved out of /*BASE/ to pools that
need it. And memory that has been released from a pool always goes
back into *BASE.

That's my understanding also. Reducing storage in a pool returns it to *BASE (whether via WRKSYSSTS, WRKSHRPOOL, the QUSCHGPA API, or via the Performance Adjuster. Increasing a pool's storage takes it from *BASE until the QBASPOOL limit is reached.

*BASE is the 'base' of memory allocations. For memory to get from
pool X to pool Y, it takes (at least) a two-step process -- first,
into *BASE; second, back out of *BASE. (Two steps... assuming
something in *BASE doesn't get involved.)

My concern gets hooked on high-priority jobs that commonly run in
*BASE. If such jobs are active, I can't see any reason why they
wouldn't have a chance at grabbing memory as soon as it arrives back
in the *BASE pool.

They can but just because storage pages are "in-use" by a job running in *BASE doesn't mean they can't be "stolen" for another pool. What will happen is that the system will write changed pages to disk and these now available pages will be transferred to the pool requesting storage. Of course, this can result in excess faulting in *BASE. If the requested storage is not available within a time limit the request will (probably) fail.

So, here are a bunch of subsystem monitor jobs, and jobs like QTCPIP
and QTCPMONITR, prestart jobs like QSQSRVR, routing entries like
QPWFSERVER, etc., -- all attempting to use *BASE directly. Paging
happens in *BASE just as it does elsewhere.

But with so many jobs competing for *BASE, how is any simple
measurement going to indicate which function is actually having trouble?

However, these jobs in *BASE are not all running at the same time. Many of them will be in transition state (Active-> Wait or Wait- >Ineligible). The number of jobs (threads really) that can have resources in *BASE at the same time (i.e., competing for storage) is controlled by QBASACTLVL. Jobs that are in a transition state will (likely) have their storage paged out.

By assigning a few shared pools and directing different kinds of
work into them, you get the first real indication of where problems
are. When *SHRPOOL10 shows high numbers, it at least narrows down to
a particular group of jobs. You don't get any extra memory, but you
at least get an indication whether more memory might be useful and
an indication why. By (maybe temporarily) splitting that group into
a couple additional pools, you narrow things farther.

Yes, always a good idea to segregate different workloads. Leave the subsystem monitors in *BASE but most of the others are good candidates for moving out.

With normal 'work' removed from *BASE, you can look at *BASE during
most intervals of a few minutes and get a quick idea of how much
'spare' memory you have at that time. The memory should be in *BASE
when it isn't needed elsewhere. (With some definite exceptions, but
those can often be calculated.)

When your system is short on memory, *BASE should stay down close to
its minimum level-- an early clue that a memory-constraint is close
or at hand. When you have more than is needed, *BASE will rise. When
extra memory is in *BASE, the performance adjuster can move it to
where it's needed essentially in a single adjustment cycle. Memory
will still route through *BASE as it moves from pool to pool, but it
is much less likely to get hijacked on its way. And a job in *BASE
won't be paged out in order to allocate the memory somewhere else.
They can still be paged out, but I'll more likely know what is being
paged because I've limited what's in _that_ pool.

The performance adjuster (apparently) has less work to do. Memory
moves more freely. Measurement increases in meaning. Guesswork is
reduced.

To me, it just makes sense to start a system right off the bat by
tossing out the IBM default pool assignments on subsystems, routing
entries, prestart jobs -- all of them. All of the great built-in
work and performance management features might as well be put to
use. If my employer is going to buy an AS/400 (or later), I might as
well make it work the best it can.

Certainly moving interactive and user batch into separate pools is a good idea. I tend to leave the rest of the stuff in *BASE until faulting rates indicate further investigation is warranted. If I had lots of ODBC/JDBC jobs then I'd move those. If I have remote users I'd move them. Using QCTL as the controlling subsystem is the minimum starting point. I move programmers into a separate subsystem and pool. I give them a separate batch queue and I throttle it.

Enough of a rant... I can't figure out why this doesn't get more
discussion. Are there so few out there who have any feeling of
certainty?

This is performance tuning--there are no certainties. It's a black art in which success is achieved only by monitoring, analysing, changing, and monitoring again. There are some things that are sensible to do on all systems and there are a few things that will do no harm but since every system is different they all may require different tuning parameters. Also, a lot has to do with the preferences and biases of the person doing the tuning.


Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------