MPDELAYZ parameter: Difference between revisions
m (minor wordsmithing) |
m (wordsmithing) |
||
| Line 18: | Line 18: | ||
This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on <var>[[SCHDOFLZ parameter|SCHDOFLZ]]</var>.</p> | This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on <var>[[SCHDOFLZ parameter|SCHDOFLZ]]</var>.</p> | ||
<p> | <p> | ||
The default value of 0 means that if the number of units of work queued to zIIP subtasks exceeds | The default <var>MPDELAYZ</var> value of 0 means that if the number of units of work queued to zIIP subtasks exceeds the limit indicated by the <var>SCHDOFLZ</var> parameter, a zIIP subtask is immediately started. The benefit of setting <var>MPDELAYZ</var> to a non-zero value is seen when a burst of work units arrive: it prevents the immediate starting of a large number of zIIP subtasks only to have most of them quickly deactivate because too many were started for the amount of work to be done. Such demand bursts are a common occurrence when dealing with critical file resource conflicts, and activating and deactivating zIIP subtasks can have non-trivial CPU costs.</p> | ||
<p> | <p> | ||
<var>MPDELAYZ</var> has no effect if either of these is true: </p> | <var>MPDELAYZ</var> has no effect if either of these is true: </p> | ||
Revision as of 19:53, 2 August 2016
Delay before activating zIIP subtask
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- On User 0's parameter line or reset by system manager.
- Related products
- All
- Introduced
- Model 204 V7.7
Description
This parameter specifies the number of milliseconds to delay starting additional zIIP/SRB subtasks when an extra one should be started based on SCHDOFLZ.
The default MPDELAYZ value of 0 means that if the number of units of work queued to zIIP subtasks exceeds the limit indicated by the SCHDOFLZ parameter, a zIIP subtask is immediately started. The benefit of setting MPDELAYZ to a non-zero value is seen when a burst of work units arrive: it prevents the immediate starting of a large number of zIIP subtasks only to have most of them quickly deactivate because too many were started for the amount of work to be done. Such demand bursts are a common occurrence when dealing with critical file resource conflicts, and activating and deactivating zIIP subtasks can have non-trivial CPU costs.
MPDELAYZ has no effect if either of these is true:
- MP/204 is not in effect in an Online (NMPSUBZ is 0).
- The number of active szIIP ubtasks (AMPSUBZ) is set to 0 or 1. (If AMPSUBZ is 1, a zIIP subtask is activated as soon as there is any zIIP runnable work, and it then runs until there is no more zIIP capable work for it to process.)
If MPDELAYZ is set, consider reducing SCHDOFLZ to 1 or 0, since both parameters attempt to solve the same problem (too much zIIP subtask activation/deactivation). Using both parameters can reduce throughput or response times.
The MPDELAY parameter provides the same functionality as MPDELAYZ for MP (non-zIIP/SRB) subtasks.
An additional benefit of using MPDELAYZ is that by delaying starting zIIP subtasks, it will delay when a MP subtask might take work from the zIIP offload queue – MP subtasks will not process zIIP work unless all AMPSUBZ zIIP subtasks are active.