NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR10N00907
Applies to: NoMachine Software
Added on: 2016-10-12
Last update: 2019-02-01
How to solve slowness problems with GNOME/KDE virtual desktops on RHEL 7 or CentOS 7

For NoMachine server v. 6.4.x or later running on Red Hat Enterprise Linux  (or CentOS) 7.5 or later please use this article: http://www.nomachine.com/AR01Q01012


In some cases, users may experience slowness when running GNOME or KDE virtual desktops.

This article provides some instructions to solve most common cases.
It applies only when VirtualGL is not in use.
To know more about VirtualGL support in NoMachine and how to enable it,  please read here: https://www.nomachine.com/AR11K00737.

 

Troubleshooting steps are:

1) Verify CPU and memory usage of the nxnode.bin process running on the server host when the NoMachine virtual desktop is insufficiently responsive.

2) Verify the OpenGL renderer in use.

and look at the corresponding case(s) below for a possible solution.


The following situations have been encountered on RHEL 7 and CentOS 7.

Summary  
Case 1: CPU power insufficient for running software rendering
Case 2: Software renderer is not optimized  

 

Case 1: CPU power insufficient for running software rendering

In NoMachine virtual desktops, OpenGL rendering is done by software components. This means that rendering tasks are accomplished by CPU and not offloaded onto GPU. Such operations could be resource-demanding , especially in the case of 3D desktop graphics effects, and make the user interface look slow.

The software component implementing the rendering is called software rasterizer. An optimized version of software rasterizer is shipped by recent GNU/Linux distribution: it is called llvmpipe as uses LLVM to do runtime code generation. Although llvmpipe runs faster than other software renderers, it is possible that the CPU is not powerful enough to run it with good performance.

Solution:

Using a less demanding desktop environment (like GNOME-classic or a lightweight desktop such as Mate or Xfce) can help.

 

Case 2: Software renderer is not optimized

GNOME 3 uses OpenGL for desktop composition. Since the rendering is done in software in NoMachine virtual display, good performance requires:

  • - Direct rendering enabled.
  • - An optimized software rasterizer.

Both requirements are accomplished by the Mesa llvmpipe driver.

It is possible that the llvmpipe driver is turned off by the installation of NVIDIA proprietary drivers. NVIDIA installer provides a libGL library optimized for the video card which doesn't ship llvmpipe. The NVIDIA installer overwrites the original libGL. Direct rendering is therefore not available in NoMachine virtual desktops and users may experience slowness and insufficient responsiveness.

Temporary solution:

Ensure that Mesa libGL is installed. On RHEL distributions, the package name is mesa-libGL:

rpm -qa mesa-libGL

Check that llvmpipe is in use. In the NoMachine session run this command in the terminal:

glxinfo | grep -i "direct rendering\|renderer string"

If everything is ok you'll get:

direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.6, 256 bits)

 

Otherwise, direct rendering will be "No" and renderer will be "Software Rasterizer".

Check the libGL in use by tracing the dependecies of glxinfo:

ldd /usr/bin/glxinfo

 

If libGL comes from NVIDIA you'll find some libnvidia libraries among dependencies.

You could uninstall NVIDIA drivers or make them cohexist with Mesa llvmpipe. In this last case, follow steps below.

All commands below must be executed in a terminal on the NoMachine server host (and on each node in case of multi-node environments) and as root user.

1)  When NVIDIA drivers are installed, you should have this softlink under /usr/lib64:

libGL.so.1 -> libGL.so.xxx.yy (xxx.yy is the NVIDIA driver version)
 

2) Move libGL.so.xxx.yy to libGL.so.xxx.yy.backup

mv /usr/lib64/libGL.so.xxx.yy  /usr/lib64/libGL.so.xxx.yy.backup
 

3) Reinstall Mesa libGL:

yum reinstall mesa-libGL.x86_64

4) Create the following directory:

mkdir /usr/local/lib64/mesa

5)  Copy Mesa libGL to the new directory:

cp -a /usr/lib64/libGL.so.1.2.0 /usr/local/lib64/mesa

6) Create the necessary soft links:

ln -s libGL.so.1.2.0 /usr/local/lib64/mesa/libGL.so.1
ln -s libGL.so.1 /usr/local/lib64/mesa/libGL.so


7) Restore NVIDIA libGL an the soft link:

mv /usr/lib64/libGL.so.xxx.yy.backup  /usr/lib64/libGL.so.xxx.yy

ln -s  libGL.so.xxx.yy /usr/lib64/libGL.so.1

8) Now, the libGL from NVIDIA is the default choice, but you can selectively switch to the MESA libGL by setting the LD_LIBRARY_PATH when running NoMachine virtual desktops.

To do that edit the /usr/NX/etc/node.cfg file to have:

DefaultDesktopCommand "env LD_LIBRARY_PATH=/usr/local/lib64/mesa gnome-session"
 

Note: If you have the NoMachine server configured to allow users select the virtual desktop type (GNOME or KDE), i.e. 'desktop=1' is set in the ConnectPolicy key of server.cfg:

ConnectPolicy autocreate=1,autoconnect=1,automigrate=1,desktop=1,dialog=1

set in /usr/NX/etc/node.cfg: 

CommandStartGnome "env LD_LIBRARY_PATH=/usr/local/lib64/mesa gnome-session"

 

9) Check the OpenGL renderer state:

glxinfo | grep -i "direct rendering\|renderer string"

If everything is correctly in place, you should get "direct rendering: Yes",
 

Note: If you get instead "direct rendering: No" , run glxinfo with debug:

LIBGL_DEBUG=1 glxinfo > glxinfo.out 2> glxinfo.err

and send the glxinfo.err and glxinfo.out file to the NoMachine Support Team for investigation.