HP 3000 Manuals HP 3000 Manuals
Skimming Along at Tree-Top Level
It's time to get back to the data. Because you still do not know why the
memory manager stopped swapping data so suddenly around 21 April, let's
examine the data more closely.
1. Close all open graphs.
_________________________________________________________________
Tip You might want to record the closing of these graphs as a
macro if you do not already have a macro that closes open
graphs. See HP LaserRX/MPE User's Manual: Analysis Software
for the procedure for recording a macro.
_________________________________________________________________
2. On the Draw Graphs dialog box, select the following:
a. Graph=Global Bottlenecks and Global System CPU Utilization.
b. X-Axis=Week.
c. Points Every...=Hour.
d. Shift=All Day.
e. Starting Day=11 April 1988.
3. Click OK.
Both graphs appear on your screen at the same time. This is an easier
way to position graphs than drawing each graph and moving them.
Your screen shows the second graph--a stacked graph--with a solid fill
pattern (hatched on a black-and-white display).
![[]](../../pic3k/M011530/FFN63c50.gif)
Global Bottlenecks and Global System CPU Utilization Graphs
Notice the gap in the data collected between 10:00 and 23:00 on 15 April.
Both graphs show the gap, but it is easier to see it on the stacked
graph. The gap occurred when SCOPE(XL) stopped collecting data. This
could have been due to a system shutdown, but you don't know this.
By aligning the X-Axes of the graphs, you can compare different
measurements at the same points in time.
In this example, you can see that whenever the memory manager values vary
on the Global Bottlenecks graph, the values also vary on the Global
System CPU Utilization graph. You already know that the memory manager
curve on the Global Bottlenecks graph represents the disc I/O rate for
memory management. Does it also represent disc I/O on the Global System
CPU Utilization graph?
Don't guess at the answer. You can use HP LaserRX's Help system to learn
that the new memory manager value is the amount of CPU time spent
managing memory. As you might expect, the CPU and disc I/O rates rise
and fall together as more and more memory management is needed.
Because this is normal, it is a good way to double-check your system.
Before assuming that a memory shortage is causing a problem, check to see
that both the CPU and disc I/O rates are high. There are cases where
memory manager CPU time is high, but there isn't any disc activity for
the memory manager. We will look at this phenomenon later.
For now it seems correct to say that Trapper is suffering from a slight
shortage of main memory, but the shortage isn't acute so this isn't a
problem. If the memory manager's swap rate increases to 10 or 20 I/Os
per second and CPU use increases to 15 or 20 percent, then there is a
problem. Trapper was a bit short of memory during the week of 11 April.
We can scroll through the data to see what happened.
But first, a few tips on scrolling. You already know how to change a
graph's starting date quickly by using the mouse to drag the scroll box
along the scroll bar. When the logfile contains a lot of data (as in
this case), you need all of your manual dexterity to position the scroll
box at exactly the right date.
As an alternative, you can advance through the logfile one day at time by
clicking the end points of the scroll box. This works well if you are
displaying a day at a time. When you are viewing a week at a time,
however, this means you will have to plot the same days over and over
again.
If you click the shaded part of the bar--between the scroll box and the
end of the scroll bar--toward the direction you want to move, you will
advance in 1-week increments. Try this on the Global Bottlenecks graph
by advancing the graph 1 week to start on 18 April.
On 21 April the memory manager's disc I/Os drop, but do they stay down?
Advance another week, and then another, to find out. Stop when you reach
2 May 1988.
It appears that once the memory manager disc I/Os drop, they remain low.
Now, using any technique you have learned, change the Global System CPU
Utilization graph to the same date (2 May 1988). Notice that once you
draw a graph, it can be scrolled independently of other graphs. Be sure
the X-Axis dates on the two graphs match before you draw any conclusions.
You see that memory manager CPU utilization drops, but not to zero the
way disc I/Os dropped. Why not? It turns out that the memory manager
also does housekeeping tasks for disc caching. These tasks use some CPU
capacity but require no disc I/O. There was no mystery; it just seemed
like one.
Conclusion
The slight memory shortage on the Trapper system ended between 21 and 22
April 1988. You observed that system activity appeared stable during
this interval. The only way you can relieve a performance bottleneck is
by obtaining more of the bottlenecked resource or using less of it. From
this, you can conclude that because the load was stable, the system used
the same amount of memory. Therefore, more memory must have been added.
Extra Credit Exercise
You also know that you must shut down a system to add more memory. When
a system is shut down to cold-load memory, there will be a gap in the
collection of performance data.
Verify this by drawing the two previous graphs with their X-Axes set to
Day. If your supposition is true, can you determine exactly when the
system was shut down and for how long? Base your determination on the
time SCOPE(XL) was not running.