Re: interpreting Gkrellm charts
On 1 June 2014 06:49, Gary Dale <garydale@torfree.net> wrote:
> On 31/05/14 03:25 PM, David wrote:
>>
>> On 1 June 2014 03:05, Gary Dale <garydale@torfree.net> wrote:
>>>
>>> On 31/05/14 12:43 PM, William Unruh wrote:
>>>>
>>>> In linux.debian.user, you wrote:
>>>>>
>>>>> I'm running Debian/Jessie on an AMD64 system using KDE. My system
>>>>> periodically grinds to a halt for a minute or so then resumes as if
>>>>> nothing had happened. This only happens when I'm running KDE. Gnome and
>>>>> xfce work properly, even with the same applications open.
>>>>>
>>>>> I recently installed Gkrellm (using default settings) to see what is
>>>>> happening when my system grinds to a halt. The only unusual part I see
>>>>> in it is that the procs box has the brown line climbing to the top of
>>>>> the chart. Interestingly, the slope of the brown line continues
>>>>> throughout the slowdown, which suggests that whatever it is measuring
>>>>> is
>>>>> continuing to increase.
>>>>
>>>> That is the number of processes that are running
>>>> The blue/green things there are how many forks there are within some
>>>> process.
>>>
>>> Possibly not. Sorry, I'm actually using the "prev" theme, not the default
>>> one (right-click on the header, select theme | prev). This shows the
>>> number
>>> of procs as a number. The number remains fairly steady over time. Under
>>> xfce
>>> (which I am currently using - this KDE problem is just too annoying), the
>>> (proc) brown line floats around a bit while the blue chart shows lots of
>>> spikes. Under KDE, the brown line goes well above the blue spikes. On the
>>> disk chart, the brown and blue charts show spikes in xcfe but jump to a
>>> solid high level under KDE during the slowdown - although I do have one
>>> saved screenshot where the disk activity shows a high number but the
>>> brown
>>> and blue charts are both at a low level.
>>
>> My interest in reading and helping with the specifics of your problem
>> pretty much evaporated when you persist in using "brown" and "blue" as
>> identifiers, even after you realise that the colors change depending
>> on the particular theme you are using. I think you are more likely to
>> receive help if you make the effort to learn what all the gkrellm
>> plots represent and present your problem in those terms instead of
>> talking about the pretty colors. That will both improve your
>> understanding of what is happening, and make it easier for people to
>> help you.
>>
>> If you right-click on the proc plot you can discover that one curve is
>> "load" and the other is "forks". The fact that one may or may not be
>> above the other is irrelevant because they both autoscale
>> independently.
>
> Actually I don't discover that at all. That information is hidden away in an
> info tab when I right-click on the Proc name bar, not in the plot area. The
> name bar doesn't respond to left-clicks, just to right clicks, while the
> chart area responds to left clicks by turning the procs and users info on
> and off.
>
> It takes a fair amount of interpretation to guess that the line is reporting
> forks while the vertical bars are possibly procs (or vice-versa) since the
> the line graph goes up and down while the number of procs reported stays
> constant. Similarly the spikes in the vertical bar chart don't seem to
> reflect the stable number of procs being reported.
>
> It would be helpful, but would require a larger interface, to have on-screen
> labels for the various graphs, such as a tool-tip style popup telling you
> what the line or bar is measuring.
>
>
>
>>
>> In the gkrellm configuration for the proc builtin, you can read the
>> info tab that explains more about that. Also in the setup of the proc
>> builtin I have entered this format string
>> \w1000\e$p\f procs\w1000\e$l\f load\n\e$u\f users\w1000\e$f\f forks
>
>
> My proc setup was \w88\a$p\f procs\n\e$u\f users. When I try yours, it shows
> two more numbers in the right side of the chart area. The top number goes
> between 0.6 and 0.8 from time to time while the bottom number jumps around
> between 1 and 6.
>
>
>
>>
>> It gives more information, but nowhere near what running 'top' offers.
>> I guess that the gkrellm curve you care about is "load", so you
>> probably need to look at the "load average" numbers in top. Searching
>> for information on this will find useful links like these:
>>
>>
>> https://www.linux.com/component/content/article/174-tutorials/42048-uncover-the-meaning-of-tops-statistics
>>
>> http://www.linuxjournal.com/article/9001
>>
>> Also 'iotop' can tell you what process is doing disk read/writes, this
>> might be helpful if you feel that the slowdown is correlated with some
>> process that is disk-intensive.
>>
>> Once you have the process ID numbers, you can use a tool like 'pstree
>> -p' to better see what initiates the offending process.
>>
>> I have no idea about KDE.
>>
>
> Unfortunately, neither top nor iotop identifies a process as doing anything
> remotely strenuous. However, iotop does confirm that the total i/o going on
> when the computer is rather a lot. This is what GKrellm also shows in a
> nicer format. The processes that iotop shows as doing a little disk activity
> are the same whether the computer is running slow or running normally. It
> doesn't seem to show what is doing the large amounts of disk I/O.
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org with a subject
> of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: https://lists.debian.org/538A4076.7070307@torfree.net
>
On 1 June 2014 06:49, Gary Dale <garydale@torfree.net> wrote:
> On 31/05/14 03:25 PM, David wrote:
>>
>> If you right-click on the proc plot you can discover that one curve is
>> "load" and the other is "forks". The fact that one may or may not be
>> above the other is irrelevant because they both autoscale
>> independently.
>
> Actually I don't discover that at all. That information is hidden away in an
> info tab when I right-click on the Proc name bar, not in the plot area. The
> name bar doesn't respond to left-clicks, just to right clicks, while the
> chart area responds to left clicks by turning the procs and users info on
> and off.
When I wrote 'If you right-click on the proc plot you can discover that one
curve is "load" and the other is "forks"', I imagined that you would realise
that you can confirm which is which by simply changing the line-style of
one of them, and observing which one's line-style is affected.
> It takes a fair amount of interpretation to guess that the line is reporting
> forks while the vertical bars are possibly procs (or vice-versa) since the
> the line graph goes up and down while the number of procs reported stays
> constant. Similarly the spikes in the vertical bar chart don't seem to
> reflect the stable number of procs being reported.
In its proc pane gkrellm provides two plots: "load" and "forks". I don't know
why you are confusing yourself by thinking one of the plots might show
procs. I'm not aware that gkrellm mentions a plot of procs anywhere.
Also, "load" is short for "load average", the references I gave explain that
this a running average, so it won't ever look spiky. And the load plot will
match the numeric value of load displayed nearby, and will also closely
track the load averages reported by top. Forks on the other hand are
typically spiky events, unless something uncontrolled is occurring.
> It would be helpful, but would require a larger interface, to have on-screen
> labels for the various graphs, such as a tool-tip style popup telling you
> what the line or bar is measuring.
Perhaps, but it's unecessary for anyone who understands what's being
plotted. There are two plots of things that show very different behaviours.
One reports instantaneous data, the other is a running average. Both plot
a numeric value displayed adjacent if using the format string I provided.
Popup tool tips are typically triggered by mousing over static GUI objects,
but a few colored pixels on a plot is not a GUI object, so that would be
complex to implement. gkrellm is a tool for sysadmins. They have learnt to
read documentation, and to think analytically. They don't need spoon
feeding obvious information.
> My proc setup was \w88\a$p\f procs\n\e$u\f users. When I try yours, it shows
> two more numbers in the right side of the chart area. The top number goes
> between 0.6 and 0.8 from time to time while the bottom number jumps around
> between 1 and 6.
Here, what you call the new "top number" is labelled "load", and what you call
the "bottom number" is labelled "forks"? Do you see those labels? If you do
see them, omitting them from this discussion and your thinking is not
helping it.
If you don't see them, perhaps you need to increase the pixel width of your
gkrellm display.
> iotop does confirm that the total i/o going on when the computer is rather a lot.
[snip]
> It doesn't seem to show what is doing the large amounts of disk I/O.
There appears to be a contradiction in those two statements, because iotop
usually shows both the total, and what comprises the total. So that's strange.
What happens if you run iotop in "only" mode while the problem is occurring?
Reply to: