Forum / NoMachine for Linux / Workstation slow for some users
- This topic has 12 replies, 2 voices, and was last updated 7 years, 7 months ago by fra81.
-
AuthorPosts
-
December 16, 2016 at 09:25 #13200mschwarzParticipant
Hello,
I’m experiencing a weird problem with the latest workstation (tested 5.1.54 and 5.1.62). System running the server is on CentOs7, clients using Windows 7 or Windows 8.1 (does not make a difference). Each user has a dedicated CentOs box to which he connects over the same connection as all others. All users use virtual desktops with xfce.
Some users experience a very slow performance while others do not. If the users switch boxes to connect to it does not help, so it seems that the box is not the issue. If I (having fast performance) connect to a collegue’s session (who has slow performance) I have slow performance to. If I create my own session on the same box with the same configuration, my performance is good.
Is there anything I can check what may lead to this behaviour? Anyone else experiencing the same?
Thanks!
Markus
December 22, 2016 at 15:09 #13253fra81ModeratorHi Markus,
that sounds strange indeed and I have no record of similar experiences.
For a start, I would note CPU and memory usage on both client and server side.
You can also gather a full set of logs as explained in https://www.nomachine.com/DT07M00098 and send them to forum[at]nomachine[dot]com, so that we can try to find a clue there.
Additionally, also session statistics might be useful (https://www.nomachine.com/DT07M00087&dn=statistics#9). Take them, if possible, for a “good” and a “bad” case.
Don’t hesitate to let us know if you spot any difference between the good and the bad cases.
January 9, 2017 at 08:44 #13445mschwarzParticipantHi,
sorry for the delay, holidays struck all of a sudden 🙂
I already gathered the statistics, the one thing I spotted is a different protocol compression ratio in NX client side statistics. The good case has 4.147:1, the bad case 2.667:1
I will gather the logs and send them in.
Thanks
Markus
January 9, 2017 at 08:44 #13446mschwarzParticipantHi again,
forgot to mention, I also spotted a difference in CPU usage, the bad case uses about twice the amount of CPU time as the good case. Memory usage seems to be about the same for both cases.
Thanks
Markus
January 9, 2017 at 12:38 #13452mschwarzParticipantHello,
I gathered all required files and attached them here in one zip.
Thanks
Markus
Attachments:
January 9, 2017 at 19:05 #13465fra81ModeratorHi Markus,
can you tell me which is the process consuming more CPU in the bad case?
January 10, 2017 at 13:03 #13470mschwarzParticipantIt’s the nxnode.bin process
January 31, 2017 at 15:56 #13648mschwarzParticipantDid you find anything in the logs? The problem still persists and is annoying the users experiencing it.
January 31, 2017 at 18:51 #13653fra81ModeratorThe logs look clean (provided they are from the “bad” case).
Did you try to disable the hardware decoding on the client (Display settings tab in the player’s menu).
February 9, 2017 at 08:24 #13737mschwarzParticipantYes, just tried it with no effect. We also updated to the new version with no improvement.
February 17, 2017 at 18:38 #13813fra81ModeratorAnother thing I would try is disabling UDP communication in the Edit connection tab.
February 23, 2017 at 10:03 #13862mschwarzParticipantJust tried it, still with no effect.
March 31, 2017 at 17:32 #14209fra81ModeratorHi Markus,
sorry again for the delay. We are still unable to reproduce this issue in our labs. We just got one report from a user that observed a couple of times that all processes started consuming more CPU and everything got fixed by a system reboot. Did you try to reboot and see if the problem settles down? Or, if the affected user creates a new session, is the new one also slower than normal? And more important, are always the same users affected, or anyone can be? Could this be happening for sessions running since a long time?
Anyway I’m afraid that, after we excluded all other cases, only thing left to do is profiling the nxnode.bin process, assuming that CPU usage is really related to the problem. Unfortunately this won’t be easy, because the profiler slows down the process itself, and so it might be hard to detect when you are reproducing the problem. If you are willing to try, please follow the instructions in https://www.nomachine.com/AR09L00809, but with a different DebugOptions key:
DebugOptions “–tool=callgrind –dump-instr=yes –callgrind-out-file=/tmp/nxnode.%p.callgrind.out”
And lastly, you mentioned CentOS 7 boxes. Are they running on top of a virtualization tool? Which one and what version? This might be what is different in our tests.
-
AuthorPosts
Closed because the user did not provide further feedback. Please notify us if you confirm that it is resolved or open a new topic if you have the same problem.