According to top or other process load tools, X is using 100% (or higher) CPU for a period of time
- X is consistently using CPU higher than normal (where normal is 1-5% typically)
- The high X load only lasts a few seconds. This is typically correct behavior.
- High memory load rather than CPU load. Different issue.
On occasion top might report high CPU usage associated with X. We get numerous bug reports about this. There are a number of causes:
Problem: Client Applications or Client-side Services
In general, most CPU loads are driven by client applications overtaxing the server. Thus, in a way the X load is the sum of client application loads. For instance, the program might be making resource-intensive xlib calls in a tight loop. In almost all such cases, closing the offending program will cause the X load to go back to normal.
The normal troubleshooting progress is to boot fresh, do whatever is needed to reproduce the high CPU loads, and then start killing processes one by one until the CPU load resolves.
An example we saw is where a daemon process does polling on X calls, such as to watch for if a monitor is present. These xrandr calls can be expensive because they do a probe and analysis of the monitor's firmware. So as a result the daemon drives X's CPU utilization through the roof (and causes a bunch of EDID stuff to fill up the Xorg.0.log). The solution in these cases is to make the daemon stop doing the expensive polling so frequently (there are cheaper X calls they can use).
Sometimes, after somebody connects or just at random, vino-server seems to go wild and pushes X Server CPU load to 80%+. Graphics will feel kind of slow. To test if this is the case, execute the following command
$ killall vino-server
If X CPU usage drops to about 10% or less then you found the problem. To work around the issue type "vino" into the Dash search box and select "Desktop Sharing". Then uncheck "Allow other users to view your desktop" in the window opened. vino-server will not be started anymore.
Problem: High CPU Due to Software Rasterizing
Most modern graphics hardware has the ability to perform graphics calculations such as image rasterizing. In theory, X's graphics drivers would rely on the hardware when it needs to do these kinds of calculations, but this is not always the case. When it does them in software rather than hardware, you will see higher CPU loads in X. Check for this via glxinfo:
$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Software Rasterizer
High CPU loads will be noted under this condition especially when moving windows, scrolling in firefox, and when compiz is enabled. This is normal - you're using the CPU to make up for the lack of GPU. Question is, where-for-art-thou GPU?
Problem: GPU Lockup
On occasion the GPU will lockup, and this will cause the CPU to exhibit a high load. This is quite rare but has been known to happen. Look at the end of /var/log/Xorg.0.log to see if any error messages are printed there. "Stuck in an infinite loop" messages are a good sign your xserver has locked up; in this case it's definitely an X bug, but be sure to file it as a "GPU lockup" bug rather than "high cpu" - high cpu is just a side effect in this case.
Other X Server Bug
In a normal, quiescent desktop system, X will require less than 10% of the CPU load. If you've ruled out the involvement of a client application and other causes listed above, the next step is to figure out what X is actually doing during these high load situations.
Running the xserver under gdb and/or strace can help identify the loop that the xserver is stuck in.