Lund Performance Solutions

SOS/3000 Wait States


SOS/3000 wait states information is displayed in the following SOS screens:
  • In the extended process line of the Process Information portion in the global screen.
  • In the Process Wait States portion of the Process Detail screen.
  • In the Workload Wait States portion of the Workload Detail screen.
  • Wait State Description

    The wait state codes defined in this glossary are specific to the performance data provided by SOS Performance Advisor.


    These states are defined in the next table.
    Table 3.1 Current Wait States
    Wait State
    Waiting for non-disc I/O to complete.
    Currently active in the CPU resource.
    This process has terminated and will not show next interval. Its last will and testament (statistics) are shown.
    Waiting for Disc I/O to complete.
    Waiting for activation by its father or son process.
    Waiting due to some resource being unavailable. An example is database locks, lack of system table entries, etc.
    Waiting for a segment(s) to be brought into memory.
    Waiting for message file I/O, port sendmail or port receivemail.
    This process has been preempted by a higher priority process.
    Waiting for a RIN to become available.
    Waiting for a timer.
    Waiting for a terminal read to complete.
    Waiting for a terminal write to complete.
    Waiting for a miscellaneous condition to complete.


    These states are defined in Table 3.2.
    Table 3.2 Wait States
    Wait State
    This wait state is the percentage of the process’ response time due to servicing by the CPU. That is, it takes time away from the CPU to perform the commands of processes.
    Performance Tip
    For processes that are computation intensive, you will usually see a high number in this category. It is possible that a process exhibiting close to 100% here is in a looping state, especially if the program has not completed as desired.
    This wait state is the percentage of the process’ response time that is due to time spent waiting for missing memory segments to return to main memory. When a process tries to continue to run but cannot because of missing necessary memory segments, that process is blocked. Memory fault stop time is counted in this category.
    Performance Tip
    There may be numbers greater than 10% in this category for systems that do not have an adequate amount of main memory to support current demands. Systems exhibiting severe memory shortage will show most user processes, which need even modest amounts of memory, as high memory wait percentages in this bucket. If only a few processes typically report values greater than or equal to 20% to 30%, you should look at their individual memory requirements. It is possible that a particular application is gorging itself on memory space. A re-design of that program might be warranted. Remember, when dealing with process brick walls (in this case absent memory segments), small percentages are desirable. Less than 10% in this wait state is preferable.
    This wait state is the percentage of the process’ response time due to waiting for missing data to be brought into main memory from disc. An I/O brick wall occurs when a process wants to continue running, but cannot because necessary user-requested data is missing from disc. Since a process literally stopped and the CPU is taken away when a physical disc access is performed, it is absolutely necessary to minimize this percentage.
    Performance Tip
    If you notice that the CPU Pause time (Global Screen) is rising above 10-15% most of the time, you will usually find that one or more processes are spending a moderate-to-high percentage of their processing time waiting for disc I/O’s to complete. If a process is consistently waiting more than 20-30% of its time on disc I/O servicing, then we should find out why. There are a number of reasons why I/O bottlenecking can take place. Some of the more common culprits are:
  • TurboIMAGE master and detail set inefficiencies.
  • Inefficient pre-fetching operation (lack of CPU, memory, poor I/O locality).
  • Too many I/O demanding processes running at once, etc.
  • Please refer to the Disc I/O and TurboIMAGE chapters in the book Taming The HP 3000 for more problem/solution information in this area.
    This wait state is the percentage of the process’ response time due to being impeded by various lock and latch control mechanisms. This category includes many stop reasons. An impede occurs when a process tries to gain access to a software table or control structure and cannot because other processes arrived first. TurboIMAGE access is one of the most common sources of impedes. When a process wants to gain entry to a particular dataset and another process has that set locked via the DBLOCK intrinsic, then the waiting process is counted as having been impeded. It must wait until the prior process is finished with its current operation before it can continue.
    Also, any file may have only one disc request outstanding. That is, in order for a process to access even a simple MPE/iX flat file, it must first gain control of that file’s control block. This access is not by the FLOCK intrinsic as is the case in the RIN wait state bucket. Rather, only one user (regardless of programmatic locking) can gain access at a time. Other sources of impedes include unavailable system table entries, terminal buffers, etc.
    Performance Tip
    The interpretation of impedes can be difficult because there are potentially many causes and inter-relationships between processes and resources. First of all, it is best to determine the overall global impede rate. This is done by looking at the Impede value on the Global Process Stop Reasons screen. If the Global Impede percentage is consistently high then it is important to look at individual processes that show high impede percentages as a part of their processing time. Processes that access the same database in applications where poor locking strategies are implemented tend to spend a very large percentage of their time being impeded. It is not uncommon to see values in excess of 60% for these processes in the impeded wait state. A large percentage may point to poor locking or simply a great deal of competition for a particular file.
    This wait state is the percentage of the process’ response time due to preemption by other processes. A preemption occurs when a process is forced to give up use of the CPU because a higher priority process is ready to execute.
    Performance Tip
    If both interactive and batch processes are running, batch processes (those in lower queues) will receive a higher number of preemptions than processes running in the interactive queue. If interactive users are spending a large percentage of their response time being preempted it is possible that there is not enough CPU horsepower to go around. Either backing off on demand or increasing the supply are your recourses. You may try doling out the CPU resource by means of the TUNE command or a program to accomplish this. The basic strategy is to give less CPU attention to those who can stand it, and provide more to those who really need it.
    This wait state is the percentage of time the process is waiting for a RIN.
    This wait state is the percentage of time the process is waiting for terminal writes to complete. Since terminal output is usually buffered, this will only accumulate time if the system runs out of terminal buffers or if the program is blocking on terminal output.
    This wait state is the percentage of time the process is waiting for non-disc I/O to complete (e.g., tape drive activity). Datacomm overhead is accumulated in this bucket as well.
    This wait state is the percentage of time the process is waiting for a programmatic timer (such as the PAUSE intrinsic) to complete.
    This wait state is the percentage of time the process is waiting on a father and/or son wait.
    This wait state is the percentage of time the process is waiting on a message file, port, or sendmail/receivemail wait.
    This wait state is the percentage of time the process is waiting on other events not covered by the above definitions.

    Lund Performance Solutions
    Voice: (541) 812-7600
    Fax: (541) 812-7611