Maximum thread number linux

What is a limit for number of threads?

I was wondering how many processes can I create on my machine (x64 with 8Gb of RAM and running Ubuntu). So I made simple master process which was continiously creating child processes, and that child processes were just sleeping all the time. I ended with just 11-12k processes. Then I switched processes to threads and got exactly same result. My pid_max is set to 32768, all per-user limits are disabled. Physical memory usage is just couple of bytes. Could you tell me what prevents the system to create new threads at that point? p.s. here is my source code for multiprocessing test written in C

#include #include int main() < pid_t pid; int count = 0; while (1) < pid = fork(); if (pid == -1) < printf("total: %d\n", count); return 0; >if (pid == 0) < while (1) sleep(10); >count++; > > 

But these bottlenecks are hitting painfully long before you reach hard limits (on number of threads or processes). So you really should benchmark your actual code.

1 Answer 1

I think you hit either a number of processes limit or a memory limit.

When I try your program on my computer and reach the pid == -1 state, fork() returns the error EAGAIN , with error message: Resource temporarily unavailable . As a normal user, I could create approx 15k processes.

There are several reasons this EAGAIN could happen, detailed in man 2 fork :

• not enough memory,
• hitting a limit like RLIMIT_NPROC,
• deadline scheduler specifics.

In my case, I think I just hit the RLIMIT_NPROC limit, aka what ulimit -u usually shows. The best is to display this limit within the program, so you have the real value, not your shell’s limits.

RLIMIT_NPROC soft: 15608, hard: 15608 total: 15242 

Which looks reasonable as I have other processes running, including a web browser.

Now, as root, the limits don’t really apply anymore and I could fork() much more: I created more than 30k processes, close to my 32k pid_max .

Now, if I take my normal user shell’s PID ( echo $$ ), and as root in another shell, I do: prlimit —pid $SHELLPID —nproc=30000 , and then launch your program in this shell, I can create almost 30k processes:

RLIMIT_NPROC soft: 30000, hard: 30000 total: 29678 

Finally: you should also consider memory usage, because on my system, I used a lot of RAM and swap to create all those processes, and maybe it was the limit you hit. Check with free .

Источник

Maximum Number of Threads per Process in Linux

The Kubernetes ecosystem is huge and quite complex, so it’s easy to forget about costs when trying out all of the exciting tools.

To avoid overspending on your Kubernetes cluster, definitely have a look at the free K8s cost monitoring tool from the automation platform CAST AI. You can view your costs in real time, allocate them, calculate burn rates for projects, spot anomalies or spikes, and get insightful reports you can share with your team.

Connect your cluster and start monitoring your K8s costs right away:

1. Overview

As we know, a process is a currently running program while a thread is a semi-process or a lightweight process.

In this tutorial, we’ll discuss what a multi-threaded process is. Also, we will learn why there’s a limit on the number of threads per process in Linux and what that limit is.

2. What Is a Multi-Threaded Process?

The provision of multiple threads of execution within the same program in shared memory space is called multithreading.

A multithreaded process enables us to run multiple threads concurrently. The purpose of multithreading is to increase performance.

For optimal performance, Linux has a limit on the number of threads. The threads-max kernel parameter can be set to ensure that the number of threads per process is always less than or equal to that limit. However, other factors like the amount of virtual memory and stack size may indirectly govern the number of threads allocated to a process.

3. Limit on Thread Count per Process

Linux has a setting for maximum threads per process, which specifies the maximum number of simultaneous executions that the process can handle.

Changes to this can throttle the process and minimize latencies for the executions that happen.

Reaching this limit means that the process needs that many threads at peak load. But, as long as it can serve requests in a timely manner, the process is adequately tuned.

However, when the limit is reached, threads queue up, potentially overloading the process. At this point, the process defers creating new threads until the number of active threads drops below the limit.

4. How to Retrieve Maximum Thread Count

The kernel parameter threads-max controls the maximum number of threads.

This parameter is defined in the file /proc/sys/kernel/threads-max.

Let’s view this file using the cat command:

$ cat /proc/sys/kernel/threads-max 63704

Here, the output 63704 indicates that the kernel can execute a maximum of 63,704 threads.

Alternatively, we can use the sysctl command to retrieve the threads-max value:

$ sysctl -a | grep threads-max kernel.threads-max = 63704

kernel.pid_max and vm.max_map_count specify two other limits that will also block the new thread creation at peak load.

The pid_max parameter specifies the value at which PIDs wrap around:

$ cat /proc/sys/kernel/pid_max 131072

The kernel.pid_max value of 131072 above means the kernel can execute a maximum of 131,072 processes simultaneously.

The max_map_count parameter specifies the maximum number of Virtual Memory Areas (VMAs) that a process can own:

$ cat /proc/sys/vm/max_map_count 65530

The vm.max_map_count value of 65530 above is the maximum number of memory map areas a process may have.

The Linux kernel handles both a process and a thread in the same way. So, values limiting the number of processes will indirectly also limit the number of threads.

Therefore, kernel.pid_max must be larger than the total number of simultaneous threads and processes.

Having many threads may consume too much memory for the server to work. vm.max_map_count limits both the virtual memory and the number of threads that require this memory for setting up their own private stack.

On systemd systems, the cgroup pids.max parameter enforces another limit. This is set to 12,288 by default. On certain occasions, this default resource limitation is not sufficient, or perhaps too restrictive.

Alternatively, performing specific adjustments on some of the systemd’s TasksMax settings may prove to be useful. The UserTasksMax parameter in the [Login] section of /etc/systemd/logind.conf overrides the default limit:

$ grep -i "^UserTasksMax" /etc/systemd/logind.conf UserTasksMax=50000

This is exactly how systemd also applies a thread limit for programs run from a login shell.

5. How to Set Maximum Thread Count

There are several ways to set the value for the maximum number of threads per process. These values determine how many threads a process will be allowed.

Let’s temporarily set the threads-max kernel parameter at runtime:

$ echo 120000 > /proc/sys/kernel/threads-max

We can permanently set the kernel.threads-max parameter by adding kernel.threads-max= to the /etc/sysctl.conf file:

$ sysctl -w kernel.threads-max=120000 >> /etc/sysctl.conf

$ echo 200000 > /proc/sys/kernel/pid_max

$ echo 600000 > /proc/sys/vm/max_map_count

$ sed -i "s/^UserTasksMax/#UserTasksMax/" /etc/systemd/system.conf $ echo "UserTasksMax=60000" >> /etc/systemd/system.conf

$ grep -i "UserTasksMax" /etc/systemd/logind.conf #UserTasksMax=50000 UserTasksMax=60000

$ ulimit -a | grep "stack size" stack size (kbytes, -s) 10240