OS/2 e-Zine! - System Monitoring in Multitasking Environments

System Monitoring in Multitasking
Environments

- by Dave Wallenberg

he focus of this article is to discuss the value of monitoring system activities in the multitasking and multithreading environment as it pertains to operating systems such as OS/2, UNIX, and Windows NT.

OS/2, UNIX, and NT are multitasking and multithreading operating systems. This means that more than one task can be performed at a time. Not only does this imply that the user can work on more than one thing at a time, but the operating system itself takes advantage of this as well and has several processes executing in the background. These processes are typically hidden from the user.

Where there can be numerous activities, there can be several resources and devices being used simultaneously. This adds a level of complexity that today's user needs to be aware of. The user may need to be aware of or desire the ability to monitor:

CPU usage to identify and resolve performance bottlenecks. This can be invaluable when trying to understand why and when your system runs slow and the ability to identify what processes cause the degradation.

Memory utilization and how much memory is currently in use, so one can gain insight into system tuning. The more components that are simultaneously active, the more memory is demanded until excess swapping occurs.

Swap utilization to identify excess and frequent swap activity when memory is over committed. This can be a good identifier for needing more memory. When physical memory is exceeded, based on the programs simultaneously running and their memory requirements, the operating system responds by temporarily "moving" pieces (4KB pages) of less active memory out to disk. These chunks of memory are brought back into memory when the memory is referenced. A Swap monitor can provide insight into excess swapping.

Program performance can enable the user to assess the impact of running program(s). Today's diverse software and multimedia craze requires the high performance of at least a i486 based or equivalent processor to keep up with CPU and memory intensive applications. The ability to examine the CPU usage of a program can help identify demanding programs and perhaps ill-behaved programs. Program monitoring can also offer the ability to see the number programs active and what state each program is in.

Disk space utilization is often desirable to monitor. How many people out there have more disk space than they know what to do with. Most people are always "tight" on disk space. As you are downloading a large file, or excess Swapping occurs, the ability to quickly view your disk space constraints can be very valuable.

Status of print spooler and print queue(s) is another valuable item to monitor. Particularly when a computer can print to LAN printers, receive and send fax documents, and more.

The three most important things in a computer have never changed. They remain, and in the following sequence, are:

The speed of the processor(s)
The amount, speed, and location of physical memory
The amount and speed of external storage disk

Program and CPU Monitoring:

The multitasking and multithreading environment of OS/2 allows numerous activities to execute simultaneously. Although each process executing appears to be sharing the same CPU concurrently, the processes are actually using individual time-slices from the OS/2 Scheduler in what is called a Priority driven Round-Robin algorithm. This means the Scheduler factors into the time-slice algorithm (amongst other items such as I/O vs CPU bound and Min/Max time-slice milliseconds) the priority of each thread within a process.

The information that the operating system maintains and collects per process and each thread within the process is stored in "Process Tables". These tables are memory resident data structures that only the operating system can access but OS/2 provides an (undocumented) API that allows access to the Process Table information. With this, the monitoring software can summarize and report the statistics in a meaningful presentation. Some of the data that can be monitored and presented to the user is:

Number of processes and threads that are running
The priority and state of threads in a process
The amount of CPU time each thread of a process has received
Which CPU each thread is attached to in SMP (Symmetric Multi-Processing) systems

These items form the basis for monitoring programs executing, how they are executing, and what amount of CPU each is consuming. This information, if presented intuitively, can be useful to any audience; whether the user be a novice or a software engineer, this real-time summary provides insight. It can be used for resolving overall system performance or performance right down to the thread level. For example, when the system appears to be "hung" or sluggish, a simple system-wide CPU monitor can inform the user as to the extent of unresponsiveness. The ability to then "zoom" into a bird's-eye view of all programs running and examine the CPU utilization per processes, usually will identify the culprit program.

Without this insight, you're at a complete loss as to what happened. The CPU monitor is typically the first monitor tool to obtain and rather simple to develop but the Process Monitor is difficult to develop and depends solely on the ability to "get at" the Process Table information of the operating system. The Process Table(s) structure is operating system specific and requires a strong understanding of the structure layout. Most new operating systems provide this raw data for applications in the form of an API. OS/2 provides much of the data to the monitoring application via an API called DosQProcStatus.

At it's best, the monitoring tool may provide an early warning mechanism. This ability would warn the user when certain thresholds have been exceeded, such as abnormal and excessive CPU usage, which may indicate a runaway situation. Before this condition brings the entire system to its knees, the user can have he opportunity to not only terminate the ill-behaved culprit, but more importantly, determine the cause. Early warning mechanisms are seen most often in real-time mission-critical systems.

Memory Monitor:

The real-time memory monitor is valuable in providing the user insight into the amount of memory that is currently in use and memory that is idle and subject to being swapped-out.

In a virtual memory model such as OS/2, the amount of actual free memory is very difficult to determine and usually calculates into an approximation. The virtual memory model simply looks at available memory as physical memory installed plus disk space available. So free memory can be two different things; actual free physical memory, or total virtual memory. Actual free memory is most often what is desired to monitor.

Tracking free physical memory, along with swap activity, enables you to determine whether you have enough memory to meet your demands. This is primarily an issue of cost, although, some may interpret it as an issue of "pain". What is your "threshold of pain" while you wait for the system to swap out memory pages to free up room for your next program?

Disk and Swap Monitoring:

Swapping is very closely related to the amount of physical memory available. At some point in the tuning process you determine your "threshold of pain". RAM costs money, but swapping is inevitable -- and normal. Unless your application is of a time-critical nature and can not afford any swap time.

The ability to monitor the frequency and degree of swapping can be the only thing you need in order to tune a system. With this alone, you can do a performance tune-up on a given system. Or at least identify if more memory is needed and how much.

Monitor Logging:

Only surface analysis tuning can be accomplished without the ability to record the monitoring activities. Periodic and continuous logging are a must for the monitoring tool.

After logging activity for a given amount of time, you have captured a sample set of statistics. This raw data can be summarized and produce minimum, maximum, and average performance reports over different time intervals, for example, peak periods.

It is important that a time-stamp is placed in the log (preferably down to a hundredth of a second). This facilitates even the most stressful situations such as real-time monitoring.

Monitor Caveats:

The monitoring software can not cause overhead. To accomplish many of the monitoring tasks discussed in this article, the monitoring software is required to periodically sample the device or system resource. Obviously, the more often samplings occur, the more system resources are used by the monitoring software. The ideal monitoring software:

Is designed to run all the time and causes absolutely no interruptions. Realizing that the PC workstation is used by the user and the typical user uses the keyboard, keyboard and video delays caused by the monitoring software mean that the monitoring software is using too much CPU to accomplish its job.
Is designed to handle a stand-alone environment as well as monitor resources in an intensive real-time environment.
Is designed to be aware of LAN connectivity.
Is designed to allow adjustable sampling rates for each resource to be monitored.
Uses staggered sampling of each resource to avoid sampling all resources at the same time. This can also be accomplished by the user by adjusting the frequency of sampling.
Exercises multithreading capabilities of the operating system so resource intensive tasks can execute at idle priorities.
Is self-contained and integrated.
Contains a logging mechanism. This is very important for unattended operations.
Has a data collection engine which serves the purpose of collecting all performance statistics. Ideally, this engine should provide APIs which allow users to interface to the software via custom programming.

Conclusions

Run one CPU monitor at a time. Attempting to run multiple CPU monitors at the same time defeats the purpose and causes each monitor to absorb the other's CPU load. Hence, each works against the other.

Depending on how robust and feature rich the monitoring software is, the software may not be able to guarantee 100% compatibility with future versions of the operating system. Due to the nature of the beast and the uniqueness of the application, most monitoring software requires slight modification per [major] operating system release. Contact the vendor before you migrate to a new release of the operating system.

Dave Wallenberg is a Principal Consultant with Computer Sciences Corporation (CSC) who functions as a Technical Architect and Software Engineer in the OS/2, UNIX, and Windows NT platforms. Independently his company, WallyWare, develops OS/2 (PM Patrol) and UNIX system monitoring tools. His work is his hobby.

--
Our Sponsors: [Bianchi Software] [BMT Micro] [ChipChat] [EmTec] [H.O.T.] [Prominic]

This page is maintained by Falcon Networking. We welcome your suggestions.