Forum / NoMachine for Linux / NoMachine server raising CPU usage on Linux Mint 17
- This topic has 5 replies, 2 voices, and was last updated 9 years, 11 months ago by fra81.
-
AuthorPosts
-
November 13, 2014 at 10:47 #5414bartwensleyParticipant
Hi,
I was using NoMachine for over a year without issue with the server running on a Ubuntu 12.04 box and the client on a Windows 7 box. I recently re-installed the server side with Linux Mint 17 (Mate desktop) and NoMachine 4.3.30. The Windows client is running version 4.2.19.
When I connect to the server, NoMachine is immediately causing problems. Although the desktop is working OK, I see the following issues:
- the mate-settings-daemon immediately rises to 60-70% CPU usage (on a single CPU)
- the nm-applet, mate-settings-daemon, nxnode.bin and any emacs processes all begin leaking memory at about 1M per minute
When googling about memory leaks under Linux Mint, I saw mention of dconf issues. I know nothing about dconf, but I noticed that as soon as I connect with NoMachine, something dconf related starts repeatedly creating/destroying a file at $HOME/.config/dconf/user.<random string>. This file is created/destroyed so quickly that it changes from one “ls” to the next.
Here is the output of the lsof command showing an example of the file:
dconf-ser 2471 bwensley 9u REG 8,1 12588 6570174 /home/bwensley/.config/dconf/user.0AY9OX
gdbus 2471 2472 bwensley 9u REG 8,1 12588 6570174 /home/bwensley/.config/dconf/user.0AY9OX
gmain 2471 2473 bwensley 9u REG 8,1 12588 6570174 /home/bwensley/.config/dconf/user.0AY9OXIs this a known issue? I searched the forums and didn’t come across anything like this.
Bart
November 13, 2014 at 18:43 #5431fra81ModeratorHi Bart,
this looks very similar to the problem reported here: http://forums.mate-desktop.org/viewtopic.php?f=5&t=2094.
Can you try the suggested workaround?
November 17, 2014 at 10:48 #5443bartwensleyParticipantThank you very much – the suggested workaround (using dconf-editor to disable the “remember-numlock-state” option) seems to work for me.
Is there something that NoMachine is doing incorrectly to trigger this issue? Is a fix planned?
Bart
November 17, 2014 at 20:23 #5487fra81ModeratorHi Bart,
it doesn’t appear to be a NoMachine problem since it was reproduced without NoMachine being involved, though it seems not clear what triggers it. Are you attaching to the physical desktop of the Mint machine? Or are you running a virtual desktop session? In the latter case, with a different user than the one logged in physically? And was the NumLock enabled/disabled on the client and the server hosts?
November 18, 2014 at 16:42 #5499bartwensleyParticipantTo answer your questions:
– I am attached to the physical desktop of the Mint machine.
– I believe the numlock was enabled on both the client and server hosts.
When I checked the server side after the problem occurred, I could see that the numlock light was flashing rapidly (that was also mentioned in the forum post you mentioned).
Not sure if it is related, but in the past, when running Ubuntu 12.04LTS on the server side, I would often notice that the status of numlock on the server would get out of sync with numlock on the client. For example, the keyboard on the client would have numlock off, but the server was producing all caps. I’m not sure what triggered this – it would sometimes happen several hours after the client was connected (I often work remotely for an entire day).
Bart
November 21, 2014 at 20:11 #5546fra81ModeratorHi Bart,
thanks for your answers. As for your old problems with Ubuntu, as far as we know all problems related to the synchronization of toggle keys should be fixed in the last version (BTW, I see you are using a quite old version on client side, various bugs have been fixed since then).
Regarding the issue with NumLock, here are a couple more links that confirm this has to be considered a bug in Mate:
https://bugs.launchpad.net/ubuntu-mate/+bug/1364111
https://github.com/mate-desktop/mate-settings-daemon/issues/57
-
AuthorPosts
This topic was marked as solved, you can't post.