Is it just me or does Xorg/Gnome seem slow and clunky to any other desktop users once the 6.7 upgrade is done?
$ uname -a Linux CentOS501.homegroannetwork 2.6.32-573.1.1.el6.x86_64 #1 SMP Sat Jul 25 17:05:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/centos-release CentOS release 6.7 (Final)
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 . . . And several instances of Xorg (one per user in addition to the shown root instance), java, FF, soffice.bin, a plugin-container for FF, ...
Using stock Gnome Desktop with three active X sessions, 6 desktops for two users, multiple FF instances with multiple tabs.
6-core AMD 3200PR with ... $ free total used free shared buffers cached Mem: 8057856 5285484 2772372 34136 298992 1883828 -/+ buffers/cache: 3102664 4955192 Swap: 14352376 0 14352376
First caught my attention as *usually* FF is the hog, although I have seen Xorg bee the hog aoccasionally in the past.
What next caught me is when using Ksnapshot to select a region of the screen the "window" no longer keeps up with my mouse movements, but lags and is "jerky".
I have no custom xorg config, but have commented out the FF startup in /etc/X11/xinit/Xclients: # Argh! Nothing good is installed. Fall back to twm { # gosh, neither fvwm95 nor fvwm2 is available; # fall back to failsafe settings [ -x /usr/bin/xsetroot ] && /usr/bin/xsetroot -solid '#222E45'
if [ -x /usr/bin/xclock ] ; then /usr/bin/xclock -geometry 100x100-5+5 & elif [ -x /usr/bin/xclock ] ; then /usr/bin/xclock -geometry 100x100-5+5 & fi if [ -x /usr/bin/xterm ] ; then /usr/bin/xterm -geometry 80x50-50+150 & fi # Commented out firefox stuff. # if [ -x /usr/bin/firefox -a -f /usr/share/doc/HTML/index.html ]; then # /usr/bin/firefox /usr/share/doc/HTML/index.html & # fi if [ -x /usr/bin/twm ] ; then exec /usr/bin/twm fi }
As a starting point I did (wrapping - I tried to clean a bit) $ ps -ef|grep '32160|32155|11398' root 841 11398 0 Aug12 ? 00:00:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display3 root 11398 1 0 Aug12 ? 00:00:00 /usr/sbin/gdm-binary -nodaemon root 11461 11398 0 Aug12 ? 00:00:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 500 24891 1441 0 17:39 pts/42 00:00:00 grep 32160|32155|11398 root 32155 11398 0 Aug12 ? 00:00:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display2 root 32160 32155 26 Aug12 tty7 09:33:09 /usr/bin/Xorg :1 -br -verbose -audit 4 auth /var/run/gdm/auth-for-gdm-4U2Ps1/database -nolisten tcp root 32221 32155 0 Aug12 ? 00:00:00 pam: gdm-password
If no one else is seeing this sort of "slowdown" and has any clues where to start looking I'd appreciate hearing your suggestions.
TIA for any thoughts, Bill
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, and does Xorg stop using a lot of CPU time if you terminate it?
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
On Fri, 2015-08-14 at 06:02 -0400, Bill Maltby (C4B) wrote:
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,
<snip>
and does Xorg stop using a lot of CPU time if you terminate it?
<snip>
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.
Ended the above FF, ksnapshot selection still lagging and jerky, CPU dropped another few points to hover around 53% or so - some improvement.
Ah! I just noticed that user still has the check for updates showing on the panel. I'll disable it, log out and in and see what X shows for CPU usage then.
Ending Evolution dropped CPU usage on Xorg down another 3% to ~50%.
Anyway, logging the user out and back in, the panel shows no checking for updates. Ksnapshot selection for the other user still lagging and jerky. CPU usage now bouncing 49%-53% with only this message composing going on and the other user on the other X session just sitting with open terminals and some openoffice spreadsheets open. soffice.bin showing about ~9%-~12% CPU usage.
<snip>
Bill
On Fri, 2015-08-14 at 06:39 -0400, Bill Maltby (C4B) wrote:
On Fri, 2015-08-14 at 06:02 -0400, Bill Maltby (C4B) wrote:
<snip>
Anyway, logging the user out and back in, the panel shows no checking for updates. Ksnapshot selection for the other user still lagging and jerky. CPU usage now bouncing 49%-53% with only this message composing going on and the other user on the other X session just sitting with open terminals and some openoffice spreadsheets open. soffice.bin showing about ~9%-~12% CPU usage.
Went and did normal backup/yum update this A.M. And saw kernel and udev/hal(?) updates and thought maybe it would help.
After doing that, logged users back in and did nothing but top in a terminal and evolution - Xorg CPU usage running around 1%.
Ksnapshot region selection still lagging big and jerky though.
Then started the normal FF, no trade screens from ADVFN applets or openoffice spreadsheets yet.
Doing nothing but watch for a minute, Xorg runs around 0.6% and other things occasionally have higher usage than Xorg. FF CPU usage is climbing slowly, flopping between 0.9%-1.3% with whatever the open tabs had in them from last session, but until tabs are accessed the page in the tab is not loaded so this is likely not the normal usage level yet.
Started on ADVFN applet (java based it looks like) and with no data flow yet the java is bouncing between 7%-11%, FF around 2%-3%, Xorg still down around 1% (might go 4% when I'm active with the keyboard, mouse, ...). Plugin container for FF around 1% now too.
Ksnapshot region selection still lagging and jerky.
So it would be easy to think some of this A.M.'s updates had a beneficial effect in one regard, CPU, usage, but not in the cluky behavior of region selection with Ksnapshot (could be a mouse driver issue introduced with the 6.7 update?).
But drawing any conclusion would be premature until I've run a normal day and see if FF keeps increasing in CPU usage like it normally does, the java applets, once I've several running, do the same, etc., and see how Xorg CPU usage and region selection with Ksnapshot behave.
I'll wrap up this thread this evening and thanks for your help Gordon!
Bill
On Fri, 2015-08-14 at 07:51 -0400, Bill Maltby (C4B) wrote:
<snip>
Ksnapshot region selection still lagging and jerky.
So it would be easy to think some of this A.M.'s updates had a beneficial effect in one regard, CPU, usage, but not in the clunky behavior of region selection with Ksnapshot (could be a mouse driver issue introduced with the 6.7 update?).
But drawing any conclusion would be premature until I've run a normal day and see if FF keeps increasing in CPU usage like it normally does, the java applets, once I've several running, do the same, etc., and see how Xorg CPU usage and region selection with Ksnapshot behave.
Xorg CPU usage did increase, as before, under certain conditions of my test, and held up very high at times when I would not have expected that (like when the things that may have caused it are left idle with no activity for hours on end).
Ksnapshot region selection had only minor, if any, improvement. This is subjective, so hard to be certain.
I'll wrap up this thread this evening and thanks for your help Gordon!
Bill
To spare the list, most of whom likely have little interest, http://pastebin.com/6Gtf99fh contains the gory details of my attempt to find causation. Undertaking it over the weekend when certain possible causes weren't available was not optimal but I don't want to take too much away from my real-life needs to overcome deficiencies introduced by new ... "features".
But I would like my 6-core AMD Linux home-built box to perform better than, or at least as well as, my *old* (2009?) 2-core HP AMD Windows 7 (now Windows 10) box. Yeah, it has more memory, 12GB vs. 8GB, and only runs a single user, but that's not enough to make much difference because it runs a really hoggish *huge* Java app all day while my Linux box just runs some spreadsheets and browser activities.
Never thought I'd see the day when an *IX box couldn't keep up with that other stuff.
One possible good may come from it - a possible clue to where to look next to fix the telinit 3/5 X screw up referenced in the big report posted in the CentOS mantis system back in ... Dec? Since RH doesn't have it I assume the same thing that caused run-level change to stop working correctly when X is active will cause it to not get fixed.
On to the topic du jour ...
First, a couple minor corrections.
I erroneously provided CPU info from one of my other boxes in the OP. Actual CPU is $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1035T Processor stepping : 0 cpu MHz : 800.000 cache size : 512 KB ... cpu cores : 6 ...
I also said "openoffice" when it's actually "libreoffice".
My preliminary conclusion is there's something in java and/or libreoffice that begins causing load on the X server once activity begins. The full effects of the java applet in FF could not be determined during the attempt to duplicate due to the lack of a data feed Saturday and Sunday.
There's apparently something somewhere that holds the X server load high even when the causative items are just sitting idle for extended periods.
The Ksnapshot region selection is still clunky (tested again after this latest closing of the all spreadsheets and libreoffice) with noticeable lag to cursor movement and jerky progression of the window borders, as compared to CentOS pre-6.7 update.
I doubt I have enough expertise to do anything more that could be worthwhile, but hope that maybe someone who has the interest and expertise might stumble upon, or pursue, a solution.
Bill
On Aug 16, 2015, at 2:39 PM, Bill Maltby (C4B) centos4bill@gmail.com wrote:
My preliminary conclusion is there's something in java and/or libreoffice that begins causing load on the X server once activity begins. The full effects of the java applet in FF could not be determined during the attempt to duplicate due to the lack of a data feed Saturday and Sunday.
I suggest going into the libreOffice settings and play around with the graphical settings (LibreOffice->View) and turn off Java (LibreOffice->Java) to see if this makes any difference. I pretty much never use the Java features in LibreOffice, and found it’s incredibly faster with it turned off.
-- Jonathan Billings billings@negate.org
On Mon, 2015-08-17 at 09:05 -0400, Jonathan Billings wrote:
On Aug 16, 2015, at 2:39 PM, Bill Maltby (C4B) centos4bill@gmail.com wrote:
My preliminary conclusion is there's something in java and/or libreoffice that begins causing load on the X server once activity begins. The full effects of the java applet in FF could not be determined during the attempt to duplicate due to the lack of a data feed Saturday and Sunday.
I suggest going into the libreOffice settings and play around with the graphical settings (LibreOffice->View) and turn off Java (LibreOffice->Java) to see if this makes any difference. I pretty much never use the Java features in LibreOffice, and found it’s incredibly faster with it turned off.
Thank you Jonathan! Will give it a try and report back after an appropriate period - likely tomorrow A.M.
-- Jonathan Billings billings@negate.org
<snip>
Bill
On Mon, 2015-08-17 at 09:30 -0400, Bill Maltby (C4B) wrote:
On Mon, 2015-08-17 at 09:05 -0400, Jonathan Billings wrote:
<snip>
I suggest going into the libreOffice settings and play around with the graphical settings (LibreOffice->View) and turn off Java (LibreOffice->Java) to see if this makes any difference. I pretty much never use the Java features in LibreOffice, and found it’s incredibly faster with it turned off.
Thank you Jonathan! Will give it a try and report back after an appropriate period - likely tomorrow A.M.
Uh-oh! Can't find that!
$ rpm -qa libreoffice* libreoffice-core-4.2.8.2-11.el6.x86_64 libreoffice-writer-4.2.8.2-11.el6.x86_64 libreoffice-draw-4.2.8.2-11.el6.x86_64 libreoffice-calc-4.2.8.2-11.el6.x86_64 libreoffice-pdfimport-4.2.8.2-11.el6.x86_64 libreoffice-math-4.2.8.2-11.el6.x86_64 libreoffice-opensymbol-fonts-4.2.8.2-11.el6.noarch libreoffice-impress-4.2.8.2-11.el6.x86_64 libreoffice-langpack-en-4.2.8.2-11.el6.x86_64 libreoffice-ure-4.2.8.2-11.el6.x86_64 libreoffice-graphicfilter-4.2.8.2-11.el6.x86_64 libreoffice-xsltfilter-4.2.8.2-11.el6.x86_64
Went to an open spreadsheet, clicked view in toolbar, nothing there that might be Java related AFAICT.
Tried on Tools->Options->LibreOffice->, nothing there looks Java related. On the graphics, only selections for hardware acceleration and anti-aliasing were available.
Tried under that LibreOffice selection all its sub-categories and under "Advanced" found "Use a Java runtime environment" with "Sun Microsystems" selection turned on. Figuring this was the one, I turned off the whole "Use a Java runtime environment".
Is this the correct one?
Anyway, stopped Libreoffice and restarted to make sure I didn't screw up my basic needs.
Came back up, so it looks like at least basic needs working.
I also looked in Tools->Options->LibreOffice Calc and saw nothing.
Thanks, Bill
On Mon, Aug 17, 2015 at 10:15:16AM -0400, Bill Maltby (C4B) wrote:
Went to an open spreadsheet, clicked view in toolbar, nothing there that might be Java related AFAICT.
Tried on Tools->Options->LibreOffice->, nothing there looks Java related. On the graphics, only selections for hardware acceleration and anti-aliasing were available.
Tried under that LibreOffice selection all its sub-categories and under "Advanced" found "Use a Java runtime environment" with "Sun Microsystems" selection turned on. Figuring this was the one, I turned off the whole "Use a Java runtime environment".
Is this the correct one?
Yes, that's what I meant. I was typing from memory. The Tools->Options dialog, under LibreOffice->Advanced. Turn off java runtime.
I also turned off 'Use hardware accelleration' and 'Use Anti-Aliasing' in LibreOffice->View. This may or may not improve X performance, at the expense of it looking worse and possibly having a slower interface.
What video card are you using? Xorg driver or proprietary binary thing?
The next thing I'd do is boot the last kernel under which you saw "normal" performance. If booting the older kernel doesn't fix the problem, then the problem is probably the X11 server. At that point, I'd start using "yum downgrade" to revert individual components, and reboot until you find the change that fixes performance. xorg-x11-server-Xorg and xorg-x11-drv-<something> are the ones I'd check first.
On Mon, 2015-08-17 at 11:14 -0700, Gordon Messmer wrote:
What video card are you using? Xorg driver or proprietary binary thing?
lspci shows
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series]
lsmod shows radeon 1734542 4
I believe this latter is the Xorg provided since I'm trying hard to just be a user since I exited the biz many years ago when I kept up with everything.
The /var/log/Xorg.0.log shows, among other things... [ 82.374] (==) Assigned the driver to the xf86ConfigLayout [ 82.374] (II) LoadModule: "ati" [ 82.377] (II) Loading /usr/lib64/xorg/modules/drivers/ati_drv.so [ 82.550] (II) Module ati: vendor="X.Org Foundation" [ 82.550] compiled for 1.15.0, module version = 7.5.99 [ 82.550] Module class: X.Org Video Driver [ 82.550] ABI class: X.Org Video Driver, version 15.0 [ 82.550] (II) LoadModule: "radeon" [ 82.550] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so [ 82.603] (II) Module radeon: vendor="X.Org Foundation" [ 82.603] compiled for 1.15.0, module version = 7.5.99 [ 82.603] Module class: X.Org Video Driver [ 82.603] ABI class: X.Org Video Driver, version 15.0
The next thing I'd do is boot the last kernel under which you saw "normal" performance. If booting the older kernel doesn't fix the problem, then the problem is probably the X11 server. At that point, I'd start using "yum downgrade" to revert individual components, and reboot until you find the change that fixes performance. xorg-x11-server-Xorg and xorg-x11-drv-<something> are the ones I'd check first.
There was a time I had the time, interest and expertise to do all that. I actually thought it was fun and worthwhile.
I've successfully transitioned to a TDU (Typical Dump User) now though and try to limit how much of my resources I devote to debugging issues caused by ... Well never mind as a list of pejorative terms related to how things are done these days seems inappropriate considering the development model used.
But I do thank you for both the suggestions and taking the time to help me get this far along. Tonight I may see some benefit from the disabling of java in libreoffice, and if so that will have been a very big help.
The Ksnapshot lagging and jerky region selection won't be as big an issue as it would have been six months or further back when I had to occasionally select very quickly very large regions on a "largeish" hi-res display when stuff was flying by very, very quickly.
My only next project is to get the new upstart .override working right to try and start gdm and gdm-binary on tty7 instead of tty1 so that telinit will work the way "God" intended instead of they way it doesn't now.
Last time I tried the .override I apparently didn't get it right as it didn't work. But I had read slap-dash and only partially so I know I should be able to get better results with a little more care.
Bill
-
Bill Maltby (C4B) -
Gordon Messmer -
Jonathan Billings