Avoid Graphical Slowdowns

bottleneck-910050_640

The top program displays a constantly updated list of running processes ordered, by default, by CPU usage. The name comes from its intended use – display the processes that are the top users of system utilization.

The joking explanation, is that it’s called “top” because it’s always at or near the top of its own output. It’s a joke, but there’s some truth to it, especially in earlier versions of the command.

How Costly Are Graphics?

Here’s a possibly alarming test. Run this command:

$ top -d 0.1

The option specifies a delay of 0.1 seconds instead of the default 3 seconds. Update the terminal window 10 times a second instead of once every 3 seconds.

On my system here at home, the resulting display is a little hard to interpret. But after watching it for a while, I conclude that from time-to-time the X process hits 10%. Usually it’s well below that and doesn’t appear in the 17 processes that fit in my 24-line terminal window. I have a 4-core CPU, so the “%CPU” column could sum to 400% if all CPUS were saturated. While that xterm window is busy, it only takes 2.5% at most of total processor capacity to update one window on the display 10 times a second.

I use the KDE desktop environment on the Mageia distribution. X, the low-level graphics display process, appears in some cycles. However, the KDE display manager itself doesn’t.

Go try that same test on Red Hat with its resource-hungry Gnome graphical environment. Watch for the gnome-shell process, that’s the desktop manager process.

Wow!

I just ran that test on a system very similar to my main desktop. The gnome-shell desktop manager process is constantly the top process, with 70–100% CPU utilization. One CPU core has been largely dedicated to updating the graphical desktop because of one text window! The X process appears in many of the cycles at about 9% use, basically the same as KDE.

What About Virtualization of a Graphical System?

I started a Windows 8.1 virtual machine using QEMU/KVM on the Linux desktop based on RHEL 7 and Gnome. Then I used virt-viewer to see and interact with the Windows graphical console. All I did on Windows was login.

It was Windows,  trying very hard to be an entertainment console. Remember the ads, when Windows 8 first came out? All those deliriously happy people dancing around their shared tables, and every single screen either prominently displaying the Netflix logo or paging through vacation pictures? The Netflix tile isn’t animated but other tiles on the default Windows desktop are constantly updating with stock quotes, entertainment “news”, sports scores, and other ephemera. I just left the Windows console viewer running, brought up a terminal window, and ran top.

Oh my. This is even worse…

The gnome-shell process constantly uses 150–200%, between 1.5 and 2 CPU cores.

Next down the list is the qemu-kvm process using about 50%, half of one of the 4 CPU cores. That is the hypervisor, the user-space process managing the virtual machine. But that VM is running Windows 8.1 and animating its desktop, plus all the unseen work emulating a complete system platform for the VM. I expect that to be a significant amount of work.

The X graphical driver is around 5–10%, as we saw before.

As for the work done by the KVM kernel modules, we can’t easily get a precise accounting for that but look at the “system” time at the top of the display. That’s total CPU time used by the kernel, KVM work is a part of that. I see the kernel using about as much CPU time as the X process.

To put it another way, the Gnome desktop manager is taking three to four times what’s needed for the entire Windows virtual machine, and twenty to thirty times what’s needed for the actual graphics.

The Windows VM seems sluggish, but much of that is because of Gnome.

Windows and Linux VMs running on top of Linux virtualization
Windows and Linux VMs running on top of Linux virtualization

You might run your VMs on a high-powered server with no graphical console, and connect to the VM consoles with virt-viewer and XSPICE the way we show you in Learning Tree’s Linux virtualization course. Or maybe you primarily use Linux as your desktop, but you need to run Windows once in a while as a VM – so you both run and view the VM from the same graphical desktop. (We also do this in the Linux virtualization course)

Either way, don’t use the Gnome desktop to interact with virtual machine consoles!

RHEL and CentOS come with the KDE desktop environment. You can install it and Gnome side-by-side and let the user choose when they login.

For better performance, use LXDE, the Lightweight X Desktop Environment.

You can easily install LXDE on Fedora, as explained here, and there is a “spin” or pre-customized Fedora with LXDE.

If you really need RHEL/CentOS 7, the easiest route starts by noting that they are based on Fedora 19. Set up a Fedora 19 YUM repository (as we show you in the Linux server administration course) and add and configure the LXDE packages as explained here.

Now your VMs can really perform without being tied down by the bottleneck of an inefficient display!

image sources

  • QEMU/KVM virtualization on Linux: Bob Cromwell

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.