Workstation slow for some users

Forum / NoMachine for Linux / Workstation slow for some users

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #13200
    mschwarz
    Participant

    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

    #13253
    fra81
    Moderator

    Hi 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.

    #13445
    mschwarz
    Participant

    Hi,

    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

    #13446
    mschwarz
    Participant

    Hi 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

    #13452
    mschwarz
    Participant

    Hello,

    I gathered all required files and attached them here in one zip.

     

    Thanks

    Markus

    Attachments:
    #13465
    fra81
    Moderator

    Hi Markus,

    can you tell me which is the process consuming more CPU in the bad case?

    #13470
    mschwarz
    Participant

    It’s the nxnode.bin process

    #13648
    mschwarz
    Participant

    Did you find anything in the logs? The problem still persists and is annoying the users experiencing it.

    #13653
    fra81
    Moderator

    The 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).

    #13737
    mschwarz
    Participant

    Yes, just tried it with no effect. We also updated to the new version with no improvement.

    #13813
    fra81
    Moderator

    Another thing I would try is disabling UDP communication in the Edit connection tab.

    #13862
    mschwarz
    Participant

    Just tried it, still with no effect.

    #14209
    fra81
    Moderator

    Hi 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.

Viewing 13 posts - 1 through 13 (of 13 total)

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.