MAXAUSER parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
Line 21: Line 21:
The idea of MAXAUSER is to try to prevent thrashing (CFR waits and server swapping) when the workload in an Online is near the 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 shot at the scarce resources. The resources used to juggle all the threads that want to run thus further reduces the resources available to perform real work, further increasing the required juggling resources. This positive feedback loop can ultimately result in an Online doing almost nothing other than server swapping and CFR waits.   
The idea of MAXAUSER is to try to prevent thrashing (CFR waits and server swapping) when the workload in an Online is near the 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 shot at the scarce resources. The resources used to juggle all the threads that want to run thus further reduces the resources available to perform real work, further increasing the required juggling resources. This positive feedback loop can ultimately result in an Online doing almost nothing other than server swapping and CFR waits.   


By setting MAXAUSER, a system manager can limit the number of users that are competing for resources by delaying 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 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 place in MAXAUSER delays rather than overlapping their processing with other threads.   
By setting MAXAUSER, a system manager can limit the number of users that are competing for resources by delaying 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 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 ideals setting of MAXAUSER would be enough so the Online can overlap as many requests as possible and so get them done
The ideals setting of MAXAUSER would be enough so the Online can overlap as many requests as possible and so get them done

Revision as of 01:50, 22 July 2014

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 idea of MAXAUSER is to try to prevent thrashing (CFR waits and server swapping) when the workload in an Online is near the 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 shot at the scarce resources. The resources used to juggle all the threads that want to run thus further reduces the resources available to perform real work, further increasing the required juggling resources. This positive feedback loop can ultimately result in an Online doing almost nothing other than server swapping and CFR waits.

By setting MAXAUSER, a system manager can limit the number of users that are competing for resources by delaying 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 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 ideals setting of MAXAUSER would be enough so the Online can overlap as many requests as possible and so get them done as quickly as possible but 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 stuff happens in the Online.

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. As such, 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 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 for per a certain number of seconds as set by the MAXAUSEW parameter.