Nxnode.bin CPU usage jumps with 5.0.58

[mpassell]

Sometime in the past few days, I let NoMachine update itself to v5.0.58 on both client and server machines (which are both running MacOS 10.10.5). When I went to log in today, everything felt really sluggish. After confirming that my network throughput seemed decent, I ran top on the server machine and noticed that while using the client to interact with the server, the CPU usage of the nxnode.bin process jumped to over 50%. That’s not normal, is it? I typically let NoMachine update itself, so I was most likely on the immediate prior version (v5.0.47?) prior to this upgrade and was not seeing any performance problems.

[mpassell]

I just tried v5.0.63 on both client and server and the situation didn’t improve. Based on the 5.0.63 release notes (security fix), I wasn’t really expecting it to, but thought it was worth a try.

[fra81]

We managed to reproduce the issue in our labs and we are working on it. It seems it is triggered by the software update process. Please check if uninstalling the software and proceeding with a fresh install solves the problem.

[mpassell]

I’m glad you managed to reproduce it. When you say uninstall, do you just mean dragging the app to the trash or some sort of more complete cleanup? (It’s annoying that Macs don’t have better hooks for full uninstalls) I tried the basic uninstall and reinstall and I’m unfortunately not seeing any improvements.

[fra81]

Dragging the app to the trash (and emptying the trash) is enough for a complete uninstallation. You mean that you reinstalled by using directly a 5.0.58 package?

Can you please send the output of this command:

$ ls /Applications/NoMachine.app/Contents/Frameworks/lib/

[mpassell]

Yes, after uninstalling, I downloaded and installed from a 5.0.58 package. Here’s the output you requested (as “ls -l”, just in case the timestamps are helpful):
-rwxr-xr-x 1 root wheel 1887296 Jan 15 06:24 libcrypto.dylib
-rwxr-xr-x 1 root wheel 181088 Jan 15 06:24 libexpat.dylib
-rwxr-xr-x 1 root wheel 298256 Jan 15 06:24 libfontconfig.dylib
-rwxr-xr-x 1 root wheel 65136 Jan 15 06:24 libfontenc.dylib
-rwxr-xr-x 1 root wheel 570512 Jan 15 06:24 libfreetype.dylib
-rwxr-xr-x 1 root wheel 305488 Jan 15 06:24 libjpeg.dylib
-rwxr-xr-x 1 root wheel 79312 Jan 15 06:24 libmdnsd.dylib
-rwxr-xr-x 1 root wheel 1110816 Jan 15 06:24 libnx.dylib
-rwxr-xr-x 1 root wheel 83376 Jan 15 06:25 libnxau.dylib
-rwxr-xr-x 1 root wheel 1142384 Jan 15 06:24 libnxc.dylib
-rwxr-xr-x 1 root wheel 326416 Jan 15 06:24 libnxcau.dylib
-rwxr-xr-x 1 root wheel 400720 Jan 15 06:24 libnxcde.dylib
-rwxr-xr-x 1 root wheel 148672 Jan 15 06:25 libnxcex.dylib
-rwxr-xr-x 1 root wheel 450128 Jan 15 06:24 libnxcim.dylib
-rwxr-xr-x 1 root wheel 131024 Jan 15 06:24 libnxcl.dylib
-rwxr-xr-x 1 root wheel 294368 Jan 15 06:24 libnxcsl.dylib
-rwxr-xr-x 1 root wheel 299600 Jan 15 06:24 libnxd.dylib
-rwxr-xr-x 1 root wheel 165248 Jan 15 06:25 libnxdi.dylib
-rwxr-xr-x 1 root wheel 955920 Jan 15 06:25 libnxdiag.dylib
-rwxr-xr-x 1 root wheel 450240 Jan 15 06:24 libnxdiex.dylib
-rwxr-xr-x 1 root wheel 1787632 Jan 15 06:24 libnxdifb.dylib
-rwxr-xr-x 1 root wheel 351552 Jan 15 06:24 libnxdift.dylib
-rwxr-xr-x 1 root wheel 277744 Jan 15 06:25 libnxdimi.dylib
-rwxr-xr-x 1 root wheel 612656 Jan 15 06:24 libnxdixl.dylib
-rwxr-xr-x 1 root wheel 83552 Jan 15 06:24 libnxesc.dylib
-rwxr-xr-x 1 root wheel 307936 Jan 15 06:24 libnxfs.dylib
-rwxr-xr-x 1 root wheel 81200 Jan 15 06:24 libnxlo.dylib
-rwxr-xr-x 1 root wheel 136448 Jan 15 06:25 libnxm.dylib
-rwxr-xr-x 1 root wheel 325984 Jan 15 06:24 libnxn.dylib
-rwxr-xr-x 1 root wheel 353136 Jan 15 06:24 libnxne.dylib
-rwxr-xr-x 1 root wheel 183120 Jan 15 06:24 libnxs.dylib
-rwxr-xr-x 1 root wheel 166576 Jan 15 06:24 libnxup.dylib
-rwxr-xr-x 1 root wheel 537232 Jan 15 06:24 libnxusb.dylib
-rwxr-xr-x 1 root wheel 61872 Jan 15 06:24 libogg.dylib
-rwxr-xr-x 1 root wheel 343088 Jan 15 06:24 libopus.dylib
-rwxr-xr-x 1 root wheel 4008912 Jan 15 06:24 libpixman.dylib
-rwxr-xr-x 1 root wheel 3390000 Jan 15 06:24 libpkcs11.dylib
-rwxr-xr-x 1 root wheel 188480 Jan 15 06:24 libpng.dylib
-rwxr-xr-x 1 root wheel 9328656 Jan 15 06:24 libqt.dylib
-rwxr-xr-x 1 root wheel 141536 Jan 15 06:24 libspeex.dylib
-rwxr-xr-x 1 root wheel 116112 Jan 15 06:24 libspeexdsp.dylib
-rwxr-xr-x 1 root wheel 230592 Jan 15 06:24 libssh.dylib
-rwxr-xr-x 1 root wheel 439328 Jan 15 06:24 libssl.dylib
-rwxr-xr-x 1 root wheel 217968 Jan 15 06:24 libvorbis.dylib
-rwxr-xr-x 1 root wheel 2768304 Jan 15 06:24 libvorbisenc.dylib
-rwxr-xr-x 1 root wheel 75344 Jan 15 06:24 libvorbisfile.dylib
-rwxr-xr-x 1 root wheel 730640 Jan 15 06:24 libvp8.dylib
-rwxr-xr-x 1 root wheel 196528 Jan 15 06:24 libwebm.dylib
-rwxr-xr-x 1 root wheel 281056 Jan 15 06:24 libyuv.dylib
-rwxr-xr-x 1 root wheel 124144 Jan 15 06:24 libz.dylib
drwxr-xr-x 22 root wheel 748 Jan 22 09:53 perl

[fra81]

Thank you for the info. Actually they exclude that your are experiencing the same problem we had found (and that will be fixed anyway in the next release). In fact from our observations the problem we found has a very limited impact.

Unfortunately we are not able to reproduce any further problem on any of the machines we tested on. Is it possible that the regression you observed is triggered by a system update? Could you maybe try to uninstall the present version and try version 5.0.47 again in order to see if you get the same results?

Another possible explanation is if you had enabled the H.264 codec with the previous version by installing the NoMachine AVC Pack or by compiling the encoding library by hand. Is this a possibility?

Please also take a ‘sample’ of the process that is consuming the CPU. You can find the option to take a sample in the Activity Monitor utility.

[mpassell]

The only way I’ve ever installed NoMachine was through a DMG (at least on a Mac), so I doubt the codec-related explanation is very likely. I’ve attached a sample from the process. I’m not sure it was spiking at the moment I took it, but at least it was pretty high (25% of CPU). If that doesn’t prove useful, I can uninstall and go back to the earlier version, but it’ll be a bit of a pain to do it before tomorrow, since uninstalling the software I’m using to connect to the machine where I’d be downgrading makes it a bit hard to do the install. 🙂 Oh, speaking of that, is it possible to install from the command line (without any GUI)? It wouldn’t be a problem for me to ssh into the machine and run an installer that way.

Attachments:

1. Sample_of_nxnode.txt

[mpassell]

Not directly related to this, I’ve also been thinking about updating to El Capitan (10.11). Any chance that might improve the situation?

[fra81]

The attached sample doesn’t seem to indicate a faulty state, as most CPU cycles are spent on diplay encoding. We are not able to say if upgrading to El Capitan will solve the problem, since we are not able to reproduce this problem with any OS X version.

Regarding your last question, here you can find how to install from command line:
https://www.nomachine.com/AR07K00683

Let us know the result of your test. The next step would be sending you a debug package, should you be willing to test it. In that case you can contact us to forum[at]nomachine[dot]com.

Also enabling the H.264 encoding would decrease the CPU usage. You can find more info in these links:
https://www.nomachine.com/AR10K00706
https://www.nomachine.com/AR10K00695

[mpassell]

Thanks for the additional instructions. Is there anywhere I can go to download v5.0.47? Once I can get my hands on it, the command line instructions should make it easy for me to install it.

I could try to get H.264 working, but it seems like overkill, especially when everything was working fine before. As I think I said, simply moving my mouse around on the remote machine’s (server’s) screen often drives the server’s CPU up over 50%. I definitely shouldn’t need an enhanced, media-focused encoding to move my mouse around. 😉

I guess I’ll make a separate decision about moving to El Capitan.

[mpassell]

Disappointingly, going back to v5.0.47 on server and client didn’t seem to help. I wonder what else changed… I noticed that H.264 was an option in the connection preferences. If I choose that without doing the extra setup described above, will it have no effect? I tried it, just in case, and it didn’t seem to have any impact.

[fra81]

Is it possible that there have been other changes in you system (e.g. a bigger monitor)?

There are a few requisites to fulfill for actually enabling H.264. Here you can find the relevant info:
https://www.nomachine.com/AR10K00706
You can check the codec currently in use in the Display settings panel from the session menu.

If you are willing to test a debug package, I renew the offer to send it to you. In that case contact us to forum[at]nomachine[dot]com.

[mpassell]

Thanks. I sent an email to forum[at]nomachine[dot]com on Monday saying that I was interested in trying out a debug version, but haven’t heard back. I recently upgraded the OS and NoMachine on both server and client to the latest (El Capitan and NoMachine v5.1.9) and now I’m having other issues (no mouse clicks registering) that I describe in a separate forum topic.

[Britgirl]

Yes, we got that 😉 and we are putting a package together. We’ll send you the details.

[Author]

Posts