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

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

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

number of threads = total virtual memory / (stack size*1024*1024)

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

проверьте машину:

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

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

повышение значений:

ulimit -s newvalue

ulimit -v newvalue

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

ссылки:

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

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

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

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

правильные потоки 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

@dragosrsupercool

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

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

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

ядра/вилки.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);

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

чтобы получить это:

cat /proc/sys/kernel/threads-max

для этого:

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

123456789 = # потоков

ограничение количества потоков:

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

как это вычисляется:

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

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

для mempages :

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

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

P. S: ограничение стога памяти потока 10M внутри моя RHEL VM, а для памяти 1.5 G Эта VM может позволить себе только 150 потоков?

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

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

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

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

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

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

зависит от вашей системы, просто напишите пример программы [ путем создания процессов в цикле ] и проверьте с помощью ps axo pid,ppid,rss,vsz,nlwp,cmd. Когда он больше не может создавать потоки, проверьте nlwp count [ nlwp-это количество потоков ] вуаля, вы получили свой дурацкий ответ вместо того, чтобы проходить через книги

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

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

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

мы можем видеть максимальное количество потоков, определенных в следующем файле в linux

cat/proc/sys/kernel / threads-max

(или)

потоки sysctl-a | grep-max

установить постоянно,

vim /etc/sysctl.conf

и добавить

kernel.threads-max = "value"

вы можете увидеть текущее значение с помощью следующей команды- cat/proc/sys/ядро / потоки-max

вы также можете установить значение типа

echo 100500 > /proc/sys/ядро / потоки-Макс

значение, которое вы установили, будет проверено на доступных страницах ОЗУ. Если структуры потоков занимают более 1/8) доступных страниц ОЗУ, thread-max будет соответственно уменьшен.

да, увеличить количество нитей нужно увеличить виртуальную память или уменьшить размер стека. В Raspberry Pi я не нашел способ увеличить виртуальную память, если уменьшить размер стека с 8 МБ по умолчанию до 1 МБ, возможно, получить более 1000 потоков на процесс, но уменьшить размер стека с помощью команды "ulimit-s" сделать это для всех потоков. Итак, моим решением было использовать "pthread_t" экземпляр "thread class", потому что pthread_t позволил мне установить размер стека для каждого потока. Наконец, я доступен для архивирования более 1000 потоков на процесс в Raspberry Pi каждый с 1 МБ стека.