MAXAUSER parameter: Difference between revisions
m (very minor spelling and grammatical edits) |
|||
| Line 19: | Line 19: | ||
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 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. | 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 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 placed 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 | The ideal 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. | 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 | 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'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 as set by the [[MAXAUSEW parameter]]. | ||
[[Category:Parameters]] | [[Category:Parameters]] | ||
Revision as of 15:39, 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 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 placed in MAXAUSER delays rather than overlapping their processing with other threads.
The ideal 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'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 as set by the MAXAUSEW parameter.