Максимальное количество потоков на процесс в Linux?

Question

Какое максимальное количество потоков может быть создано процессом в Linux?

Как (если возможно) можно изменить это значение?

Answer 1

В Linux нет отдельных потоков на лимит процессов, только ограничение на общее количество процессов в системе (потоки - это, по сути, просто процессы с общим адресным пространством в Linux), которое вы можете посмотреть так: *

cat /proc/sys/kernel/threads-max

По умолчанию используется количество страниц памяти / 4. Вы можете увеличить это как:

echo 100000 > /proc/sys/kernel/threads-max

Существует также ограничение на количество процессов (и, следовательно, потоков), которые может создать один пользователь, подробности относительно этих ограничений см. В ulimit/getrlimit.

Answer 2

Неверно утверждать, что в LINUX нет отдельных потоков на ограничение процесса.

Linux реализует максимальное количество потоков на процесс косвенно !!

number of threads = total virtual memory / (stack size1024)

Таким образом, количество потоков на процесс может быть увеличено путем увеличения общей виртуальной памяти или уменьшения размера стека. Но слишком большое уменьшение размера стека может привести к сбою кода из-за переполнения стека, а максимальная виртуальная память равна памяти подкачки.

Проверьте свою машину:

Общая виртуальная память: ulimit -v (значение по умолчанию не ограничено, поэтому вам нужно увеличить объем подкачки, чтобы увеличить это)

Общий размер стека: ulimit -s (по умолчанию 8Mb)

Команда для увеличения этих значений: *1024*

ulimit -s newvalue

ulimit -v newvalue

* Замените новое значение значением, которое вы хотите установить в качестве предела.

Ссылка:

http://dustycodes.wordpress.com/2012/02/09/increasing-number-of-threads-per-process/

Answer 3

На практике ограничение обычно определяется пространством стека. Если каждый поток получает 1 МБ стека (я не помню, если это по умолчанию в Linux), то у вас 32-разрядная система исчерпает адресное пространство после 3000 потоков (при условии, что последний ГБ зарезервирован для ядра) .

Однако вы, скорее всего, будете испытывать ужасную производительность, если будете использовать более нескольких десятков потоков. Рано или поздно вы получаете слишком много накладных расходов на переключение контекста, слишком много накладных расходов в планировщике и так далее. (Создание большого количества потоков делает немного больше, чем просто потребляет много памяти. Но большое количество потоков с реальной работой будет замедлять вас, поскольку они борются за доступное время процессора)

Что вы делаете, когда этот предел даже актуален?

Answer 4

правильных 100k потоков в Linux:

ulimit -s  256
ulimit -i  120000
echo 120000 > /proc/sys/kernel/threads-max
echo 600000 > /proc/sys/vm/max_map_count
echo 200000 > /proc/sys/kernel/pid_max 

 ./100k-pthread-create-app

2018 обновление от @Thomas, в системах systemd:

/etc/systemd/logind.conf: UserTasksMax=100000

Answer 5

@ dragosrsupercool

Linux не использует виртуальную память для вычисления максимального потока, но физический ОЗУ установлен в системе

 max_threads = totalram_pages / (8 * 8192 / 4096);

http://kavassalis.com/2011/03/linux-and-the-maximum-number-of-processes-threads/

ядро ​​/ fork.c

/* The default maximum number of threads is set to a safe
 * value: the thread structures can take up at most half
 * of memory.
 */
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

Таким образом, максимальный поток в каждой системе различен, поскольку установленная память может быть разных размеров, я знаю, что Linux не нужно увеличивать виртуальную память, потому что на 32-разрядной системе мы получили 3 ГБ для пользовательского пространства и 1 ГБ для в ядре, в 64-битной системе мы получили 128 ТБ виртуальной памяти, что происходит в Solaris, если вы хотите увеличить виртуальную память, вам нужно добавить пространство подкачки.

Answer 6

Чтобы получить его:

cat /proc/sys/kernel/threads-max

Чтобы установить его:

echo 123456789 > /proc/sys/kernel/threads-max

123456789 = количество потоков

Answer 7

Предел количества нитей:

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

Как рассчитывается:

max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);

и: размер страницы x86_64 (PAGE_SIZE) составляет 4 КБ; Как и во всех других архитектурах, x86_64 имеет стек ядра для каждого активного потока. Эти стеки потоков имеют размер THREAD_SIZE (2 * PAGE_SIZE);

для mempages:

cat /proc/zoneinfo | grep spanned | awk '{totalpages=totalpages+$2} END {print totalpages}';

так что на самом деле это число не связано с ограничением размера стека памяти потока (ulimit -s).

P.S .: ограничение стека памяти в моей виртуальной виртуальной машине составляет 10 МБ, а для 1,5 ГБ памяти эта виртуальная машина может позволить себе только 150 потоков?

Answer 8

Это, вероятно, не должно иметь значения. Вы достигнете гораздо большей производительности, если будете разрабатывать алгоритм с использованием фиксированного числа потоков (например, 4 или 8, если у вас 4 или 8 процессоров). Вы можете сделать это с рабочими очередями, асинхронным вводом-выводом или чем-то вроде libevent.

Answer 9

проверьте размер стека на поток с помощью ulimit, в моем случае Redhat Linux 2.6:

    ulimit -a
...
    stack size              (kbytes, -s) 10240

Каждый из ваших потоков получит этот объем памяти (10 МБ), выделенный для его стека. С 32-битной программой и максимальным адресным пространством 4 ГБ, это максимум только 4096 МБ / 10 МБ = 409 потоков !!! Минус программный код, минус пространство кучи, вероятно, приведет к наблюдаемому макс. из 300 нитей.

Вы должны иметь возможность поднять это, скомпилировав и запустив на 64-битной системе или установив ulimit -s 8192 или даже ulimit -s 4096. Но если это целесообразно, другое обсуждение ...

Answer 10

Для тех, кто смотрит на это сейчас, в системах systemd (в моем случае, в частности, в Ubuntu 16.04) есть еще одно ограничение, устанавливаемое параметром cgroup pids.max.

По умолчанию установлено значение 12 288, и его можно переопределить в /etc/systemd/logind.conf

.

По-прежнему действуют другие рекомендации, включая pids_max, threads-max, max_maps_count, ulimits и т. Д.