MAXAUSER parameter: Difference between revisions

Latest revision as of 20:44, 7 June 2016

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).

@@ Line 17: / Line 17: @@
 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.
+An <b>interactive</b> user for the purposes of <var>MAXAUSER</var> processing is a web thread or a 3270 thread. These threads are considered <b>active</b> 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 <code>WEBLOGON</code> 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.
+The purpose of <var>MAXAUSER</var> 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&nbsp;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.
-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.
+===Setting MAXAUSER===
+By setting <var>MAXAUSER</var>, 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 <var>MAXAUSER</var> threshold. While a delayed user might suffer a server swap for the <var>MAXAUSER</var> 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.
-The ideals setting of MAXAUSER would be enough so the Online can overlap as many requests as possible and so get them done
+Setting <var>MAXAUSER</var> 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 <var>MAXAUSER</var> delays, rather than overlapping their processing with other threads.
-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.
+The ideal setting of <var>MAXAUSER</var> is simultaneously both of these:
+<ul>
+<li>High enough so the Online can overlap as many requests as possible and so get them done as quickly as possible. </li>
+<li>Not so high as to allow requests to thrash. </li>
+</ul>
+Probably the correct setting of <var>MAXAUSER</var> is somewhat less than <var>[[NSERVS parameter|NSERVS]]</var>, 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 <var>MAXAUSER</var> parameter can be used to reduce thrashing in times of stress. However, it can be useful to know if <var>MAXAUSER</var> is actually causing users to be delayed, as frequent <var>MAXAUSER</var> delays would suggest that an Online doesn't have sufficient resources to run its workload.
+Therefore, when users are delayed because of the <var>MAXAUSER</var> setting, a message (<code>MSIR.1042: Delaying user for MAXAUSER</code>) 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 <var>[[MAXAUSEW parameter|MAXAUSEW]]</var> parameter).
-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]].
 [[Category:Parameters]]