Forum / NoMachine for Linux / Latest versions, kworker process high CPU
- This topic has 4 replies, 2 voices, and was last updated 10 years, 8 months ago by
fidelleon.
-
AuthorPosts
-
December 10, 2013 at 11:37 #1210
fidelleon
ParticipantI’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?
December 10, 2013 at 12:38 #1218fra81
ModeratorI’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.
December 10, 2013 at 14:59 #1219fra81
ModeratorUpdate:
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.
December 10, 2013 at 15:41 #1220fra81
ModeratorUpdate2:
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.
December 10, 2013 at 18:41 #1221fidelleon
ParticipantConfirmed 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] -
AuthorPosts
This topic was marked as solved, you can't post.