NoMachine server, as any other application, utilizes system resources to function properly.

If the available system resources are exceeded, users may be no longer able to create new virtual desktop, custom session etc... with NoMachine.

In this case it's necessary to increase resource limits. To change resource limits permanently and override the default system settings, administrators have to modify the /etc/security/limits.conf file and ensure that the system relies on this file. This file permits to set limits for all users or for specific users.

Error messages in console may show the cause of the problem.

Events related to exhaustion of system resources can be also found in NoMachine logs on client and server side. Collecting and reviewing them can be helpful to diagnose the problem (How to collect logs: https://www.nomachine.com/DT10O00163).

1. Troubleshooting

1.1. How to check availability of system resources on the NoMachine server host

When it's no longer possible to create new NoMachine sessions, or performance becomes slow, it's suggested to inspect the available system resources and limits set on the Linux host where NoMachine server is installed. 

To do that, use the following commands:

top / htop   for tracking processes & their CPU consumption

free  for tracking available memory (unused and used RAM memory and swap space)

Although RAM memory is available, process limits can be exceeded:   

cat /proc/sys/kernel/threads-max   to see limit on the total number of processes on the system (threads)

ulimit -a   to see all current limits set for the logged user who runs the command

sudo grep -nr ERROR /usr/NX/var/log/   to find eventual errors reported in NoMachine logs

Note that the amount of RAM memory consumed by NoMachine is variable and depends on many factors (e.g. creating a custom session with a simple text editor will consume less resources than creating a virtual desktop with GNOME environment).
NoMachine performance is closely related to system as well as to hardware efficiency. Creating virtual and custom sessions implies the creation of new threads that, depending on the enviroment and on the application type, may require different amount of resources.
You may refer to the following article for some benchmark tests made on version 6: https://www.nomachine.com/AR02P00966.

Here we are presenting some of the most common cases of exhaustion of system resources and how to determine them.

1.2. Error 'Resource temporarily unavailable' (too many processes running)

NoMachine logs report:

14516 14516 14:01:57 571.575 Thread: ERROR! Thread creation failed.
14516 14516 14:01:57 571.786 Thread: ERROR! Error is 11 'Resource temporarily unavailable'.
 

To see the maximum number of processes available to a single user, run:

ulimit -u

To check how many processes a user has, run:

ps -L -u <username> | wc -l

IMPORTANT:
At least one nxserver process is started for each session (two in case of reconnection to a virtual desktop or custom session). All of these nxserver processes  are running as user 'nx', please check the limits set for the user 'nx' as well. In case of large installation it's common to reach the 'maximum number of processes' for the nx user.

Note also that 'number of processes' is referring to threads, each 'nxserver --login' process has usually 12 threads.

1.3. Error 'Resource temporarily unavailable' (exhaustion of virtual memory resources)

NoMachine logs report:

2903 2945 12:40:16 895.512 Thread: ERROR! Thread creation failed.

2903 2945 12:40:16 895.874 Thread: ERROR! Error is 11 'Resource temporarily unavailable'.

2903 2945 12:40:16 896.019 Scheduler/Scheduler: ERROR! Failed to create the slave thread.

Error: Failed to create the slave thread.

To see the maximum amount of virtual memory available to the process, use:
ulimit -v

1.4. Error 'Too many open files'

NoMachine logs report:

2017-04-21 10:46:31 038.745 2622 NXNODE WARNING! Couldn't create pipe. Error is EMFILE, Too many open files

2017-04-21 10:46:31 038.788 2622 NXNODE ERROR! Cannot create mono pipe for child stdout.

2017-04-21 10:46:31 038.826 2622 NXNODE ERROR! Error is: 24, Too many open files.
 

To check how many open files a user has, run:

lsof -Fn -u <username>| sort | uniq | wc -l

(on some OS it is: /usr/sbin/lsof -Fn -u <username>| sort | uniq | wc -l )

To see the per-user limit of maximum open file descriptors, run:
ulimit -n

Note for systems using Systemd

Depending on Systemd configuration, it's possible that limits set in /etc/security/limits.conf are ignored.

In this case even when ulimit is set, the user's limit of maximum open file descriptors in the NoMachine session is still different.

For example if the /etc/security/limits.conf file has set:

   <username>  -    nofile          800108
   nx                  -    nofile          800108
   nxhtd             -    nofile          800108
   
the user still has open files limit 1024 as set in systemd configuration.

Systemd limits are set in the following files:
/etc/systemd/system.conf
/etc/systemd/user.conf

We recommend to refer to the official documentation of systemd for your OS to change settings.

If instead of error 24 NoMachine logs report:

2020-01-20 10:28:05 079.983 97449 NXSERVER WARNING! Error is: 23, 'Too many open files in system'.

it means that the maximum number of open files is reached globally.

To check how many files is open in the system, execute:

lsof -Fn | sort | uniq | wc -l

To check the global limit of open files run:

cat /proc/sys/fs/file-max

or:

sysctl fs.file-max

To modify the value in current session, run:

sysctl -w fs.file-max=(new_value)

To make the change persistent after reboot add following line in /etc/sysctl.conf file:

fs.file-max=(new_value)

1.5. Error 'Not enough X resources'

Every session requires a set of free ports which are calculated based on DISPLAY. If no free port is available, error 'Not enough X resources' is issued. Increasing the display limit in the server configuration (/usr/NX/etc/server.cfg) will increase the pool of available displays.

2. How to increase resource limits

If you’re a system administrator you may want to change limits set to specific values depending on your needs. To set limits permanently, it's possible to add system-wide rules or rules for specific users and groups of users. These rules are set in the system configuration file, /etc/security/limits.conf. Please refer to the official documentation of your Linux distribution for detailed instructions
Note that it's necessary to increase both hard limits and soft limits, when applicable.

Some examples of rules set in the /etc/security/limits.conf for a specific user are below.

2.1. System: increase the maximum number of processes

<username> hard nproc <number>
<username> soft nproc <number>

For example:
nxtest01 hard nproc 16384
nxtest01 soft nproc 16384

For the nx user it's advisable to set 'unlimited':
nx soft nproc unlimited
nx hard nproc unlimited

Note for RHEL 6/CentOS 6:
Setting nproc in /etc/security/limits.conf does not works correctly on RHEL 6 and is overwritten by /etc/security/limits.d/90-nproc.conf.
Asa workaround, set the limit in one of those files, and disable the other one. Ref. https://access.redhat.com/solutions/146233

2.2. System: increase the maximum number of open files

<username> hard nofile <number>
<username> soft nofile <number>

For example:
nxtest01 hard nofile 63536
nxtest01 soft nofile 63536

Note:
'nofile' limit cannot be higher than value defined in /proc/sys/fs/file-max.

2.3. System: increase the maximum virtual memory (KB)

<username> hard as <number>
<username> soft as <number>

For example, to limit RAM usage to 4G for user nxtest01:
nxtest01 hard as 4000000
nxtest01 soft as 4000000

or to make it unlimited:
nxtest01 hard as unlimited
nxtest01 soft as unlimited

2.4. System: increase the maximum stack size (KB)

<username>  hard stack <number>
<username>  soft stack <number>

For example:
nxtest01 hard stack 8192
nxtest01 soft stack 8192

2.5. System: increase the maximum PID number

The maximum value for the Process ID is by default set to 32768 on Linux. You can read the value set in your system in the /proc/sys/kernel/pid_max file.

On 64bit systems it's possible to increase that limit by increasing value of kernel.pid_max in /etc/sysctl.conf. The maximum accepted value is 4.194.304, setting an higher value will make the system to use the default value.

2.6. NoMachine: increase the maximum display number

Edit the NoMachine server configuration file, /usr/NX/etc/server.cfg and increase the value set for the DisplayLimit key, for example:
DisplayLimit 400
It's not necessary to restart the NoMachine server, just run a new session.