|System Monitoring in Multitasking|
|- 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 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:
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.
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?
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.
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.
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.
-- Copyright © 1996 - Falcon Networking
Our Sponsors: [Bianchi Software] [BMT Micro] [ChipChat] [EmTec] [H.O.T.] [Prominic]
This page is maintained by Falcon Networking. We welcome your suggestions.
Copyright © 1996 - Falcon Networking