MAXAUSER parameter - Revision history

JAL: minor formatting

2016-06-07T20:44:54Z

minor formatting

← Older revision		Revision as of 20:44, 7 June 2016
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.		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 of 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 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 placed 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 ideal 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'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]]

JDamon: very minor spelling and grammatical edits

2014-07-22T15:39:31Z

very minor spelling and grammatical edits

← Older revision		Revision as of 15:39, 22 July 2014
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 ~~ideals~~ setting of MAXAUSER would be enough so the Online can overlap as many requests as possible and so get them done		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 ~~for~~ per a certain number of seconds as set by the [[MAXAUSEW 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'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]]

Goff: /* Description */

2014-07-22T01:50:31Z

Description

← Older revision		Revision as of 01:50, 22 July 2014
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

Alex at 12:57, 17 April 2014

2014-04-17T12:57:04Z

← Older revision		Revision as of 12:57, 17 April 2014
Line 25:		Line 25:
	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
	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 for per a certain number of seconds as set by the [[MAXAUSEW parameter]].
	[[Category:Parameters]]		[[Category:Parameters]]

Alex: Created page with "{{Template:MAXAUSER parameter subtitle}} ==Summary==

Default value
0
Parameter type
System
Where set
On User 0's parameter line or reset by system..."

2014-04-17T12:45:27Z

Created page with "{{Template:MAXAUSER parameter subtitle}} ==Summary== <dl> <dt>Default value <dd>0 <dt>Parameter type <dd>System <dt>Where set <dd>On User 0's parameter line or reset by system..."

New page

{{Template:MAXAUSER parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>On User 0's parameter line or reset by system manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Sirius Mods</var> 8.0 and <var class="product">Model 204</var> 7.5.
</dl>

==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 place 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.
[[Category:Parameters]]

MAXAUSER parameter - Revision history

JAL: minor formatting

JDamon: very minor spelling and grammatical edits

Goff: /* Description */

Alex at 12:57, 17 April 2014

Alex: Created page with "{{Template:MAXAUSER parameter subtitle}} ==Summary== Default value 0 Parameter type System Where set On User 0's parameter line or reset by system..."

Alex: Created page with "{{Template:MAXAUSER parameter subtitle}} ==Summary==

Default value
0
Parameter type
System
Where set
On User 0's parameter line or reset by system..."