11 thoughts on - Clunky Xorg With Latest 6.7 Upgrade?

• Well, what’s process 23391, and does Xorg stop using a lot of CPU time if you terminate it?

• 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_launched1669392988 -D__applet_launched1669388124
  -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_launched2798004959 -D__applet_launched2798001805
  -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

  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:

  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.

  Bill

• 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

• 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.

  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

• 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

• Thank you Jonathan! Will give it a try and report back after an appropriate period – likely tomorrow A.M.

  Bill

• 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

• 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- are the ones I’d check first.

• 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

  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