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?