SDAEMDEL parameter
SDaemon swap delay (MS)
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- System manager resettable
- Related products
- All
- Introduced
- Sirius Mods 7.7
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:
- A swap for a parent thread waiting for the daemon.
- A swap of a daemon thread waiting for the parent.
- 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.
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.