Name
Abstract | ||
|---|---|---|
The more complex a computer system is, the more important it is to get relevant information about its operational state. In
a multi-user environment, there is usually an operator or administrator who is responsible for smooth operation. He or she
needs to be aware of any abnormal behavior, e.g. node failure, overload situations, deadlocks (avoidance), bottlenecks or
other situations related to availability and performance. To that end, a console is used to inform the operator about the
state and the behavior of the machine at one single place.
In a system with a single copy of the operating system (e.g. an SMP system), such a console is a standard feature. An SCI
cluster, however, is more complicated. Although it provides physically shared memory and can therefore be considered a NUMA
multiprocessor, its ”look and feel” to the user is rather a collection of autonomous nodes each running a complete and independent
local operating system. Redirecting console output of the individual nodes to a central terminal is possible but not sufficient,
since a node usually simply crashes without sending a message in advance. An operator of an SCI cluster would have to probe
the nodes to make sure that all of them are up and running.
In addition to the operational states of the nodes, the operator also wants more detailed information about the utilization
and performance of the system, since any anomaly in system behavior may indicate a situation that needs human intervention.
A component that provides this kind of information is usually called a monitor. A monitor observes the system by sampling relevant system measures, such as utilization, throughput, and other quantities
and makes these measurements available for on-line or off-line analysis. In a multi-programming environment, it should be
possible to attribute the measured quantities to the individual programs, offering some insight into their behavior. By providing
this functionality, a monitor can help the programmer debug the parallel program or reveal design flaws leading to poor performance.
The monitor provides a global bird’s-eye view of the system, which is usually not available in a distributed system.
In the following, we present a monitoring tool that has been developed for SCI cluster computers. Section 25.2 gives an overview
of its general structure. Sections 25.3 – 25.5 describe the major components and the way they interact. A short conclusion
in Section 25.6 closes this chapter.
|
Year | DOI | Venue |
|---|---|---|
1999 | 10.1007/10704208_33 | Scalable Coherent Interface |
Keywords | Field | DocType |
monitoring sci clusters,distributed system,operating system,cluster computing,shared memory | Cluster (physics),User Datagram Protocol,Computer science,Deadlock,Abnormality,Computer network,Transmission Control Protocol,Operator (computer programming),Deadlock prevention algorithms,Distributed shared memory | Conference |
ISBN | Citations | PageRank |
3-540-66696-6 | 0 | 0.34 |
References | Authors | |
1 | 3 | |
Name | Order | Citations | PageRank |
|---|---|---|---|
| Matthias Maier-Stahel | 1 | 0 | 0.34 |
| Roger Butenuth | 2 | 8 | 2.96 |
| Hans-ulrich Heiss | 3 | 209 | 29.25 |