MAXAUSER parameter

Maximum active interactive users

Summary

Default value

0

Parameter type

System

Where set

On User 0's parameter line or reset by system manager

Related products

All

Introduced

Sirius Mods 8.0 and Model 204 7.5.

Description

Sets the maximum number of "active" "interactive" users allowed at a time. The default of 0 means there is no limit.

An interactive user for the purposes of MAXAUSER processing is a web thread or a 3270 thread. These threads are considered active when they are not in a screen input wait or not processing a web request. A web thread in a persistent session request wait or a WEBLOGON wait is not considered active.

The purpose of MAXAUSER is to prevent thrashing (CFR waits and server swapping) when the workload in an Online is near the limit of resources (CPU, disk I/O) available to handle the load. In such a situation, Model 204 (like most systems in such a scenario) can thrash, using up even more resources in a vain attempt to give every thread a decent opportunity to obtain the scarce resources. As a consequence, the use of resources to juggle all the threads that want to run only further reduces the resources available to perform real work, thus further increasing the required juggling of resources. This positive feedback loop can ultimately result in an Online doing almost nothing other than server swapping and CFR waits.

Setting MAXAUSER

By setting MAXAUSER, a system manager can limit the number of users that are competing for resources. The parameter can delay users (before they become active) until the number of active users goes below the MAXAUSER threshold. While a delayed user might suffer a server swap for the MAXAUSER delay, the hope is that once the user is made active, it will be competing with fewer threads for resources, so it should be able to get its work done faster. In this way, overall system throughput might increase.

Setting MAXAUSER too low, however, might result in the Online not being able to fully utilize all the resources available to it, because threads are artificially placed in MAXAUSER delays, rather than overlapping their processing with other threads.

The ideal setting of MAXAUSER is simultaneously both of these:

• High enough so the Online can overlap as many requests as possible and so get them done as quickly as possible.
• Not so high as to allow requests to thrash.

Probably the correct setting of MAXAUSER is somewhat less than NSERVS, where the "somewhat" depends on how much non-web, non-3270 activity happens in the Online.

Reporting MAXAUSER delays

Ideally, the resources available to an Online will always be sufficient to immediately and quickly process all requests. If this is not the case, the MAXAUSER parameter can be used to reduce thrashing in times of stress. However, it can be useful to know if MAXAUSER is actually causing users to be delayed, as frequent MAXAUSER delays would suggest that an Online doesn't have sufficient resources to run its workload.

Therefore, when users are delayed because of the MAXAUSER setting, a message (MSIR.1042: Delaying user for MAXAUSER) is issued. By default this message goes to the job log and operator's console. Of course, issuing thousands of such messages in a time of stress could make things even worse, so these messages are limited to one per a certain number of seconds (set by the MAXAUSEW parameter).