Latest versions, kworker process high CPU

[fidelleon]

I’ve been using Nomachine 4 for a while to connect from Linux to a Linux box. I’ve noted last versions of Nomachine (maybe the 4.36x series) put a kworker process to high CPU utilization, making almost unusable the remote physical desktop. As soon as I disconnect such process lowers its CPU use but keeps taking CPU.

I’ve tested it with Fedora 19 and Xubuntu 13.10 in the remote box, fully patched and updated. I have disabled every non-essential service on Nomachine’s server setup. As soon as I send a “systemcll stop nxserver” or “/etc/init.d/nxserver stop” the kworker process stops using CPU.

Any ideas?

[fra81]

I’ve noted last versions of Nomachine (maybe the 4.36x series) put a kworker process to high CPU utilization, making almost unusable the remote physical desktop

For the moment for this release, there have been no changes that may affect CPU usage for quite a while, so I don’t think it’s directly related to changes to the NoMachine software. It seems more connected to a change to the Linux system. This kworker processes are started by the kernel for various reasons, for example to handle I/O or interrupts, except that there is no new I/O or interrupt compared to the software released 1 or 2 months ago.

Please send the output of the top command taken while somebody is connected to the physical desktop and while the NoMachine system is idle. Take the same output using top -H (this will show the threads one by one). Include the exact version of the Linux kernel you are using (so we can possibly try to reproduce it), the exact version of the NoMachine software and, if possible, the logs on the server (check here how to get them: https://www.nomachine.com/AR07K00677). If there is any thread entering a loop eating CPU it should be easy to find out which one it is from top and the logs.

[fra81]

Update:

we tried on multiple Fedora 19 and Ubuntu 13.10 machines and we reproduced the problem on one of them. The description you gave matches 100%. The source of the problem is in the USB kernel module. Unloading it fixes the CPU problem.

Edit /usr/NX/etc/node.cfg and set EnableUSBSharing key to “none”. Restart the server with /usr/NX/bin/nxserver –restart. Please confirm that the workaround works.

[fra81]

Update2:

good news, it seems. The latest version of the USB module that is ready but was held in testing doesn’t show this behavior. If you are so kind to contact the support, we’ll send you the sources you can compile (just run “make”) and put in the correct place to test.

[fidelleon]

Confirmed that disabling USB sharing workaround has fixed the issue for me on a Fedora 19 3.11.10-200.fc19.x86_64 box. No kworker taking CPU cycles:

 2452 fidel     20   0 3020952 0,978g  35172 R  60,6 12,5 647:20.88 /usr/lib64/firefox/firefox -new-instance -P fidel
2567 fidel     20   0 2008472 737540  26644 R  39,0  9,0 467:10.20 /usr/lib64/firefox/firefox -new-instance -P TX
1060 root      20   0  181556  49356  31632 S  17,2  0,6 321:12.98 /usr/bin/X -background none :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt1 -novtsw+
2818 fidel     20   0  688040  93732  11504 R  11,9  1,1 102:27.61 /usr/lib64/firefox/xulrunner/plugin-container /usr/lib64/flash-plugin/libflashplayer.so+
2587 fidel     20   0 1948312 654592  26764 S   9,3  8,0 390:07.07 /usr/lib64/firefox/firefox -new-instance -P JL
4005 fidel      0 -20 1523064 113364  41048 S   7,9  1,4   0:18.45 /usr/NX/bin/nxnode.bin
2905 fidel     20   0  688040 102500  11516 S   2,6  1,3  69:42.64 /usr/lib64/firefox/xulrunner/plugin-container /usr/lib64/flash-plugin/libflashplayer.so+
4402 fidel      0 -20 1374364  70956  11248 S   0,3  0,9   0:01.21 /usr/NX/bin/nxnode.bin -H 6
4557 root      20   0  123696   1672   1160 R   0,3  0,0   0:00.07 top
32548 root      20   0       0      0      0 S   0,3  0,0   0:01.28 [kworker/u8:0] 

[Author]

Posts