SDAEMDEL parameter - Revision history

DCameron: /* Description */

2017-05-24T14:59:35Z

Description

← Older revision		Revision as of 14:59, 24 May 2017
Line 59:		Line 59:
	If there is lots of daemon activity in a resource constrained Online, this can result in 204 not being able to do productive work because it's too busy shuffling daemon and parent threads into and out of servers.		If there is lots of daemon activity in a resource constrained Online, this can result in 204 not being able to do productive work because it's too busy shuffling daemon and parent threads into and out of servers.

	The expected symptom of such a situation (when server swapping is being done in memory) is one task spending almost all its time server swapping and, in an MP environment, an inability to keep the other tasks busy.		The expected symptom of such a situation (when server swapping is being done in memory) is one task spending almost all its time server swapping and, in an <var>[[MP/204#Multiprocessing_.28MP.2F204.29\|MP]]</var> environment, an inability to keep the other tasks busy.
	The number of tasks that can be kept busy is simply a function of the amount of work that can be done between swappable waits and has nothing to do with how much work there is to do because 204 can't swap users in fast enough to keep all the MP tasks busy.		The number of tasks that can be kept busy is simply a function of the amount of work that can be done between swappable waits and has nothing to do with how much work there is to do because 204 can't swap users in fast enough to keep all the MP tasks busy.

	[[Category:System parameters]]		[[Category:System parameters]]
	[[Category:Parameters]]		[[Category:Parameters]]

DmeWiccan: Automatically generated page update

2013-08-27T16:43:44Z

Automatically generated page update

New page

{{Template:SDAEMDEL parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager resettable
<dt>Related products
<dd>All
<dt>Introduced
<dd>Sirius Mods 7.7
</dl>
==Description==
This parameter indicates the number of milliseconds to
delay (hence SDAEMDEL) before allowing a daemon or
parent thread to be swapped out when it's waiting for
the other. The default value of SDAEMDEL is 0 which
means that there will be no delay. A value bigger than
32767 (32.767 seconds) is treated as 32767 in Sirius Mods 7.7
and in Sirius Mods 7.8 and later, values bigger than 32767 are not allowed.

The goal of setting SDAEMDEL is to prevent server swaps
for quick parent/daemon interactions while allowing them
for longer interactions. So, if 90% of the parent/daemon
interactions are less than, say, 10 milliseconds
(parent tells daemon to do something and the daemon
responds within 10 millisconds and then the parent
tells the daemon to do something else within 10
milliseconds), setting SDAEMDEL could be a big win in
reducing server I/O. On the other hand, setting SDAEMDEL
too high can result in servers being tied up with
parent or daemon threads that have been idle for quite a
while.

A worst case scenario that would be significantly helped
by setting SDAEMDEL is a New/Run/Discard sequence. In
this sequence, if the Online is thrashing, both the
parent and daemon will suffer a server swap in/out
sequence for each method, resulting in 12 server swaps
for this simple sequence.

SDAEMDEL will delay three kinds of server swaps:
<ol>
<li>A swap for a parent thread waiting for the daemon.</li>
<li>A swap of a daemon thread waiting for the parent.</li>
<li>A swap of an sdaemon thread waiting for the next unit
of work. This delay affects '''all''' sdaemon threads,
including those used for daemon objects, $commxxx
requests, web requests, server socket requests and so
on. Since sdaemon threads are reused on an MRU basis,
SDAEMDEL can eliminate many server swaps associated
with an sdaemon going idle for an instant before being
reused for another purpose.</li>
</ol>

Since SDAEMDEL is intended to prevent server swaps for '''quick''' interactions between the parent and daemon thread, and since server swaps should generally not occur for the brief waits resulting from these interactions, SDAEMDEL is only likely to have an effect in situations where there is a lot of server swapping happening.
If there is lots of daemon activity in a resource constrained Online, this can result in 204 not being able to do productive work because it's too busy shuffling daemon and parent threads into and out of servers.

The expected symptom of such a situation (when server swapping is being done in memory) is one task spending almost all its time server swapping and, in an MP environment, an inability to keep the other tasks busy.
The number of tasks that can be kept busy is simply a function of the amount of work that can be done between swappable waits and has nothing to do with how much work there is to do because 204 can't swap users in fast enough to keep all the MP tasks busy.

[[Category:System parameters]]
[[Category:Parameters]]

Dme: /* Description */

2010-10-02T15:42:03Z

Description

New page

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager resettable
<dt>Related products
<dd>All
<dt>Introduced
<dd>Sirius Mods 7.7
</dl>
==Description==
This parameter indicates the number of milliseconds to
delay (hence SDAEMDEL) before allowing a daemon or
parent thread to be swapped out when it's waiting for
the other. The default value of SDAEMDEL is 0 which
means that there will be no delay. A value bigger than
32767 (32.767 seconds) is treated as 32767 in Sirius Mods 7.7
and in Sirius Mods 7.8 and later, values bigger than 32767 are not allowed.

The goal of setting SDAEMDEL is to prevent server swaps
for quick parent/daemon interactions while allowing them
for longer interactions. So, if 90% of the parent/daemon
interactions are less than, say, 10 milliseconds
(parent tells daemon to do something and the daemon
responds within 10 millisconds and then the parent
tells the daemon to do something else within 10
milliseconds), setting SDAEMDEL could be a big win in
reducing server I/O. On the other hand, setting SDAEMDEL
too high can result in servers being tied up with
parent or daemon threads that have been idle for quite a
while.

A worst case scenario that would be significantly helped
by setting SDAEMDEL is a New/Run/Discard sequence. In
this sequence, if the Online is thrashing, both the
parent and daemon will suffer a server swap in/out
sequence for each method, resulting in 12 server swaps
for this simple sequence.

SDAEMDEL will delay three kinds of server swaps:
<ol>
<li>A swap for a parent thread waiting for the daemon.</li>
<li>A swap of a daemon thread waiting for the parent.</li>
<li>A swap of an sdaemon thread waiting for the next unit
of work. This delay affects '''all''' sdaemon threads,
including those used for daemon objects, $commxxx
requests, web requests, server socket requests and so
on. Since sdaemon threads are reused on an MRU basis,
SDAEMDEL can eliminate many server swaps associated
with an sdaemon going idle for an instant before being
reused for another purpose.</li>
</ol>

Since SDAEMDEL is intended to prevent server swaps for '''quick''' interactions between the parent and daemon thread, and since server swaps should generally not occur for the brief waits resulting from these interactions, SDAEMDEL is only likely to have an effect in situations where there is a lot of server swapping happening.
If there is lots of daemon activity in a resource constrained Online, this can result in 204 not being able to do productive work because it's too busy shuffling daemon and parent threads into and out of servers.

The expected symptom of such a situation (when server swapping is being done in memory) is one task spending almost all its time server swapping and, in an MP environment, an inability to keep the other tasks busy.
The number of tasks that can be kept busy is simply a function of the amount of work that can be done between swappable waits and has nothing to do with how much work there is to do because 204 can't swap users in fast enough to keep all the MP tasks busy.

[[Category:System Parameters]]
[[Category:Parameters]]

Alex: Created page with "==Summary==

Default value
0
Parameter type
System
Where set
System manager resettable
Related products
All
Introduced
Sirius Mods 7.7..."

2010-09-23T23:48:34Z

Created page with "==Summary== <dl> <dt>Default value <dd>0 <dt>Parameter type <dd>System <dt>Where set <dd>System manager resettable <dt>Related products <dd>All <dt>Introduced <dd>Sirius Mods 7.7..."

New page

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager resettable
<dt>Related products
<dd>All
<dt>Introduced
<dd>Sirius Mods 7.7
</dl>
==Description==
This parameter indicates the number of milliseconds to
delay (hence SDAEMDEL) before allowing a daemon or
parent thread to be swapped out when it's waiting for
the other. The default value of SDAEMDEL is 0 which
means that there will be no delay. A value bigger than
32767 (32.767 seconds) is treated as 32767 in Sirius Mods 7,7
and in Sirius Mods 7.8 and later, values bigger than 32767 are not allowed.

The goal of setting SDAEMDEL is to prevent server swaps
for quick parent/daemon interactions while allowing them
for longer interactions. So, if 90% of the parent/daemon
interactions are less than, say, 10 milliseconds
(parent tells daemon to do something and the daemon
responds within 10 millisconds and then the parent
tells the daemon to do something else within 10
milliseconds), setting SDAEMDEL could be a big win in
reducing server I/O. On the other hand, setting SDAEMDEL
too high can result in servers being tied up with
parent or daemon threads that have been idle for quite a
while.

A worst case scenario that would be significantly helped
by setting SDAEMDEL is a New/Run/Discard sequence. In
this sequence, if the Online is thrashing, both the
parent and daemon will suffer a server swap in/out
sequence for each method, resulting in 12 server swaps
for this simple sequence.

SDAEMDEL will delay three kinds of server swaps:
<ol>
<li>A swap for a parent thread waiting for the daemon.</li>
<li>A swap of a daemon thread waiting for the parent.</li>
<li>A swap of an sdaemon thread waiting for the next unit
of work. This delay affects '''all''' sdaemon threads,
including those used for daemon objects, $commxxx
requests, web requests, server socket requests and so
on. Since sdaemon threads are reused on an MRU basis,
SDAEMDEL can eliminate many server swaps associated
with an sdaemon going idle for an instant before being
reused for another purpose.</li>
</ol>

Since SDAEMDEL is intended to prevent server swaps for '''quick''' interactions between the parent and daemon thread, and since server swaps should generally not occur for the brief waits resulting from these interactions, SDAEMDEL is only likely to have an effect in situations where there is a lot of server swapping happening.
If there is lots of daemon activity in a resource constrained Online, this can result in 204 not being able to do productive work because it's too busy shuffling daemon and parent threads into and out of servers.

The expected symptom of such a situation (when server swapping is being done in memory) is one task spending almost all its time server swapping and, in an MP environment, an inability to keep the other tasks busy.
The number of tasks that can be kept busy is simply a function of the amount of work that can be done between swappable waits and has nothing to do with how much work there is to do because 204 can't swap users in fast enough to keep all the MP tasks busy.

[[Category:System Parameters]]

SDAEMDEL parameter - Revision history

DCameron: /* Description */

DmeWiccan: Automatically generated page update

Dme: /* Description */

Alex: Created page with "==Summary== Default value 0 Parameter type System Where set System manager resettable Related products All Introduced Sirius Mods 7.7..."

Alex: Created page with "==Summary==

Default value
0
Parameter type
System
Where set
System manager resettable
Related products
All
Introduced
Sirius Mods 7.7..."