Product Documentation
Abstract
This is a list of commonly seen IBM i tasks and their functions.
Content
Table is sorted alphabetically:
| Task Name | What it does |
|---|---|
| #w#a#i#t#T#a#s#k |
Dedicated processor LPARs will accumulate execution time in the wait-state task when the processor is idle (i.e. all threads idle).
Shared processor LPARs should not accumulate execution time in the wait-state task when the processor is idle. When one thread is idle and one non-idle, the wait-state task (running in the idle thread) will accumulate execution time. If utilization was really 100%, there would be no accumulation of execution time in the task.
|
| CFINT## |
CFINT## tasks are LIC tasks that essentially do nothing at all. They are just tasks that we charge with the CPU cycles that were used for hardware interrupts.
When an I/O completes from disk, tape, or comm I/O, for example, a hardware interrupt is sent to the partition.
The hardware interrupt arrives at a processor and there are CPU cycles spent routing the completion back to the job or task that requested the I/O. Those CPU cycles used during that processing aren't charged back to the job or task that requested the I/O but are charged to CFINT## instead. |
| CFSLT## |
CFSLTnn tasks are pseudo tasks reported in Collection Services to aggregate short-lived SLIC tasks. This is an enhancement that was added in 7.1. Rather than cluttering CS with data for many SLIC tasks that live for a very short time (less than 1 second) and are generally unimportant, the data for each of those tasks is aggregated into a single representative task.
Usually there is one such representative task per node (so the ## is a hex encoding of the node ID - all of the short lived tasks whose home node is node 0 get aggregated into the CFSLT00 task).
Tip: Load/dump tasks frequently qualify as short-lived and so most this is the most likely thing you may be seeing there.
|
| DBIO* | These tasks manage the auxiliary space associated with database files. Auxiliary space is the space associated with variable length character fields. Any job doing operations on files with variable length character fields (for example, a purge job) might cause these jobs to become active. |
| DBL3Base* | These tasks are used during parallel database operations, such as parallel index builds or EVI scans. |
| DBPMServer* | These tasks are responsible for pre-bringing auxiliary (AUX) segments. AUX segments are associated with variable length character fields. |
| DD-FREEAGENT* |
The DD- tasks handle DASD hardware driver functions that cannot be performed on a client task. They are used for:
- internal DD commands on startup or during resets
- dasd microcode downloads - dasd initialization/format processing - dasd error recovery processing - IoStats retrieve measurements requests |
|
IOAM*
IOAM-#####-1
IOAM-#####-2
|
Each storage adapter has 3 IOA manager tasks. For each adapter, the task labeled IOAM--#########-02 is the one that would process query multi adapter status/query array config. |
| IOSTATSTASK | This task retrieves I/O measurements. It is used by many functions including WRKDSKSTS, WRKSYSSTS, save/restore functions, queries, etc. |
| JO-DESTROY-### | This task is usually seen when issuing DLTJRNRCV. The base segment of the receiver is deleted in the user job but the rest of the segments that make up the receiver are deleted in this background task. This is done to make the delete faster so that the user job doesn't have to wait. |
|
JO-EVALUATE*
JO-EVALUATE-TASK
|
These tasks have to do with SMAPP (EDTRCYAP). If a file that is not explicitly journaled is opened, and the system journals it implicitly, this task can kick in. It evaluates indexes, estimates rebuild time for an index, and may start or stop implicit journaling of an index or a keyed access path.
This task can also appear when objects have a change in their journaling status. It starts/ends journaling to/from the internal SMAPP journal and user journals. It should only hold seizes briefly. The exception to this is if you have a complex DB network where access paths are built over multiple PFs which may have other APs over them. In that case, when journaling is started/ended on one of these files, the database has to seize the whole network.
|
| JO-RECRA | These are SLIC Journal Recovery Ratio housekeeping tasks. |
| JO-SERV-LV2--## | JO-SERV tasks are created at IPL and perform multiple functions to support other operations. They may be used for apply, rollback, vary on, etc. |
| LDCKMN | The number of LDCKMN tasks would indicate the number of saves that were using SWA. |
| LDCSxxx | Used for SWA. There will usually be 14 of these tasks created per save session. |
| LDDOIM | The number of LDDOIM tasks would indicate the number of save processes active. |
| LDLOIM | The number of LDLOIM tasks would indicate the number of restore processes active. |
| LDMAIN | The number of LDMAIN tasks would indicate how many S/R processes are active. |
| LDSUBxx | Used for by any save job. There will be 14 of these tasks created per save session. |
| LMBAFFINITYFIX | When a DPO occurs, or storage management detects memory that has not been seen previously (indicating that the hypervisor has altered the physical memory layout of the partition), the OS needs to verify that every page of main store is where it thought it was. Without doing this fix up, all future memory allocations may be incorrect from an affinity standpoint. This task runs through memory one page at a time attempting to rectify the OS view of memory with the actual memory layout after it has been changed by the hypervisor. |
| MASOSERVICETASK |
This task is associated with MUTEX cleanup. It can impact machine pool faulting and a VLOG is produced when it runs. Normally, applications should clean up their mutexes, and this task should NOT have to run.
How often the task runs is determined by a threshold value based on the current number of mutexes + 16K. The MASOSERVICE task will run and will examine all mutexes on the system. It will determine which are active and which are leaked. It will then clean up the leaked (dangling) ones. It will then add 16K to the number of mutexes active and when that new threshold is reached it will run the MASOSERVICE task again.
|
| MNTASK | This task is used for Context (Library) management. It processes requests to force out the changed object list portion of a library. The number of objects being created/destroyed would have an impact on how active MNTASK is. |
| P0FBAIT* | The P0FBAIT#### tasks perform asynchronous reads on behalf of jobs using stream files. It brings the pages into the memory pool where the job using the file runs. |
| RCRCLMSUnnONTRAC | These tasks are active when someone is running a RTVDSKINF or RCLSTG on the system. |
| RMMOVETASKOBJCTS | Task for moving in-memory objects between pool nodes. It is more efficient to have an object in a node closer to the processor that is currently processing the object. |
| RMTMSAFETA* | A timer task that services LIC timer function requests that are not handled by an interrupt handler task already in main storage. |
| SMDSTASK* |
These tasks do I/O for another task or threads that are not performed using SAR (virtual addresses). The requester has already looked up the disk unit, location, and these tasks perform what is known as "Page" or "Sector" I/O.
Tip: Most of the time this task is seen with Save/Restore operations but may also used for I/O related to IXA/IXS servers.
|
| SMEHDRWORK* |
These tasks perform cleanup of internal headers to prevent possible issues with directory recovery. After they complete they are not seen again.
Tip: If these tasks are using high resources, they can be paused via an AA macro.
|
|
SMEQ*
SMBALUNIT
SMIOCOLLECT
SMTRCTASK SMDASDUTILTASK |
These tasks are used to process STRASPBAL.
Tip: You can read more about them and STRASPBAL here:
https://www-01.ibm.com/support/docview.wss?uid=nas8N1019618
|
| SMFSCLEAN* |
These tasks convert dirty disk freespace into clean freespace.
Tip: If you see machine gating in these tasks or if you need further information on them, you can review this document:
|
|
SMIOSTCPGFST*
SMIOSTCPGSLW*
|
These tasks are used to complete big brings. SAR events will show who is performing the big brings. More correctly, these tasks are used to redrive multi-part IO, both reads and writes. There are two queues - FST for writes, and SLW for reads. The reason for the distinction is that a multi-part read may need to wait for a page to be freed which could result in a write and it couldn't complete if on the same queue. Asynchronous IO pending requests can also be routed to these tasks. |
| SMLSTIM* | The task is for lightning SIDs which are new in 7.4. Lightning SIDs are small (3 pages or less) temporary SIDs that have no backing store, or temporary directory entry until they are written, or have some ASM operation done on them (changing storage protection for example). Historically 99% of small temporary SIDs are simply created and destroyed without ever being written, so IBMi is trying to reduce disk fragmentation by never allocating DASD for them. The timer task manages these SIDs. If they are more than a minute old it automatically converts them to temporary SIDs. |
| SMPLACLRTASK* | This task clears PLA (process local address space). When new teraspace storage gets allocated this task initializes it to x'00's. |
| SMPOLnnn | This is the low-priority page out task. |
| SMPOnnnn | This is the high-priority page out task. |
| SMXCAGER## |
This is the Expert Cache pool ager task. There is one task per memory pool where ## is the pool number.
In addition to aging pages in the pool, these tasks will write any changed pages they encounter while processing the available list of pages in the pool. So if the pool is not busy, it will not fill up with changed pages that prevent the OS from stealing a page if there was suddenly demand for pages of memory. Each ager task will use 10% of the system's DASD requests to issue asynchronous writes before switching to use synchronous writes. |
|
VLTASK
SMVLOG-RECORDER
|
These tasks are associated with VLOG generation.
Tip: If you see them using CPU constantly, that means that something on the system is constantly generating VLOG entries.
|
Document Location
Worldwide
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]
Document Information
Modified date:
29 October 2020
UID
ibm10871316