On Thu, 2015-08-13 at 23:51 -0700, Gordon Messmer wrote:
> On 08/13/2015 02:44 PM, Bill Maltby (C4B) wrote:
> > Top shows
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 32160 root 20 0 259m 104m 22m R 76.5 1.3 559:07.79 Xorg
> > 23391 hardtolo 20 0 6293m 215m 26m S 16.9 2.7 21:49.86 java
>
> Well, what's process 23391,
Looks like its java plugins to run trade screens application from ADVFN
(Investorshub). But that's no different than what I was running before
the update to CentOS 6.7.
Edited below to increase readability.
$ps -ef|grep '23391\|20075'
501 20075 504 0 Aug13 ? 00:01:33 /usr/lib64/firefox/plugin-container
/usr/java/jre1.8.0_51/lib/amd64/libnpjp2.so
-greomni /usr/lib64/firefox/omni.ja
-appomni /usr/lib64/firefox/browser/omni.ja
-appdir /usr/lib64/firefox/browser 504 plugin
501 23391 20075 12 Aug13 ? 01:44:21 /usr/java/jre1.8.0_51/bin/java
-D__jvm_launched=121669392988 -D__applet_launched=121669388124
-Xbootclasspath/a:/usr/java/jre1.8.0_51/lib/deploy.jar:
/usr/java/jre1.8.0_51/lib/javaws.jar:
/usr/java/jre1.8.0_51/lib/plugin.jar
-Djava.class.path=/usr/java/jre1.8.0_51/classes -Dsun.awt.warmup=true
-Djava.security.manager sun.plugin2.main.client.PluginMain
write_pipe_name=/tmp/jpi-200753075568327304565826
501 23675 20075 9 Aug13 ? 01:19:43 /usr/java/jre1.8.0_51/bin/java
-D__jvm_launched=122798004959 -D__applet_launched=122798001805
-Xbootclasspath/a:/usr/java/jre1.8.0_51/lib/deploy.jar:
/usr/java/jre1.8.0_51/lib/javaws.jar:/usr/java/jre1.8.0_51/lib/plugin.jar
-Djava.class.path=/usr/java/jre1.8.0_51/classes -Dsun.awt.warmup=true
-Djava.security.manager sun.plugin2.main.client.PluginMain
write_pipe_name=/tmp/jpi-200755060440780511431914
500 28264 1441 0 05:06 pts/42 00:00:00 grep 23391\|20075
> and does Xorg stop using a lot of CPU time
> if you terminate it?
It should (Ill report test results below), as in the past when FF, or
its plugins container started hogging CPU I would terminate these, and
other browser pages that were hit by a lot of scripts to do ads and
fancy useless visual things, CPU usage for FF, plugins container and
Xorg all would drop.
But as I mentioned, all this same stuff was going on before the 6.7
update. I would keep an eye on FF CPU and when it got unreasonably high
I would close pages or even end FF and restart and problems were
ameliorated for a while. It seems that FF accumulates resources and has
an ever-increasing CPU usage with what I normally have running.
But even in those cases I didn't see a "jerky" and lagging selection
window when I was selecting a region with ksnapshot. The usual symptom
was a slow redraw of FF windows when I switched between them or betwee
virtual desktops. I am *not* seeing those symptoms with the current
issue - looks like FF and plugins container (I wonder if I can eliminate
that - not sure it's needed?) is behaving OK.
Ended the trade screens applet and tried selection of a region with
ksnapshot - same results were a lag and jerkiness. I checked all the
open FF windows to see if I had other known hog applets runing but
didn't see any.
Trying shutting down FF and restarting, which used to provide some
temporary relief - like Alka-seltzer.
After shutting down FF and before restarting FF, region selection still
lagging and jerky. Top shows
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32160 root 20 0 221m 75m 13m R 68.7 1.0 1192:08 Xorg
2025 hardtolo 20 0 1479m 281m 78m R 14.6 3.6 226:35.72 soffice.bin
1035 wild-bil 20 0 1116m 315m 43m S 7.6 4.0 196:15.91 firefox
The FF above is different user, with which there are generally no
effects because of low usage. Xorg dropped from 76.5% at the time I
posted yesterday. So even with that heavy user's FF shutdown, Xork (a
new snigglet?!) is taking a big slice of CPU time when the only thing
happening interactively is me editing this reply.
I don't have enough insight to know if that's normal for X/Gnome setups.
I'm afraid I'm stuck with this like the telinit 3/5 change fiasco where
things no longer work like they used to (or at all in that case). RH (or
whoever) is taking a path I'll have trouble staying on I guess.
Thanks for taking the time Gordon!
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
