boost :: thread_resource_error, когда более 32705 потоков

Question

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

Алгоритм легко написать, если я помещу каждое сообщение в свой собственный поток ииспользуйте boost :: condition, чтобы приостановить поток, пока не будет доступна вся необходимая информация.Я создаю много тысяч тем, но в большинстве случаев активны только немногие.Кажется, это работает очень хорошо.

Моя проблема в том, что при модульном тестировании я обнаруживаю, что если я создаю более 32705 потоков, я получаю

неизвестное местоположение (0): фатальноошибка в "Tree_test": std :: exception: boost :: thread_resource_error

, и я не знаю, что вызывает это или как это исправить.

Кажется, что имеется достаточное количество доступной памяти (каждый поток содержит только два указателя - объекты, между которыми проходит сообщение).

Из этого вопроса: Максимальное количество потоков на процесс в Linux? Я думаю, что следующая информация является подходящей (хотя я действительно не знаю, что это значит ...)

~> cat /proc/sys/kernel/threads-max
1000000

(я увеличил это с 60120 - нужно ли перезапускать?)

 ~>ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Я попытался поиграть с ожидающими сигналами (мой предел очень близок к 2 * этому числу) и размером стека с ulimit -S -i 8191 - (я не смог увеличить его), но эти изменения, похоже, не далиэффект вообще)

Я на 64-битной Ubuntu-10-10, если этот помогает ...

Answer 1

Я думаю, что с 32K-потоками в системе, вам следует взглянуть на потенциальные решения, отличные от того, как получить больше потоков.Например, пул потоков (у Boost есть кое-что для этого).

В любом случае, в вашей системе не ограничены ли PID 32768 или какое-то подобное значение?Я думаю, вы рано или поздно закончите, а также можете спроектировать систему, позволяющую обрабатывать больше элементов, чем максимальное количество потоков.

Тем не менее, посмотрите на / proc / sys /kernel / pid_max, чтобы увидеть ваш максимальный PID - и попробуйте увеличить его.Это может вывести вас за пределы 32 КБ (но также может вызвать непредвиденное поведение с программами, не предназначенными для необычно больших PID, поэтому будьте осторожны).

И тогда вы можете быть ограничены пространством стека (в отличие от пространства виртуальной памяти).Вы можете попробовать создавать темы с меньшими стеками, если хотите.

Answer 2

Это действительно зависит от того, насколько велики ваши стеки, но вам не хватит адресного пространства (32-битная) или виртуальной памяти (64-битная), если вы создадите много потоков.

В Linux pthreads размер стека по умолчанию был 10 Мб в прошлый раз, когда я проверял; это означает, что 32k-потоки используют 320G адресного пространства (обратите внимание, что оно, вероятно, будет инициализироваться лениво, поэтому не будет использовать столько виртуальной памяти); это, вероятно, слишком много.

Даже если вы сделаете стек довольно маленьким и не исчерпаете память таким образом, потоки 32 КБ будут использовать много виртуальной памяти для стеков. Попробуйте использовать другой подход.

ulimit влияет только на размер стека исходного потока (который обычно динамический в Linux); размер стека других потоков фиксируется и устанавливается во время создания потока библиотекой pthread.

Answer 3

Хорошо, чтобы ответить на вопрос: вам нужно увеличить

/proc/sys/vm/max_map_count

Как обсуждено здесь:

https://listman.redhat.com/archives/phil-list/2003-August/msg00025.html

и здесь:

http://www.kegel.com/c10k.html#limits.threads

ОДНАКО: ДЛЯ ЛУЧШЕГО СПОСОБА ЭТОГО СМОТРЕТЬ НА СЛЕДУЮЩИЙ ВОПРОС:

Непоточная альтернатива ожиданию условия(Изменить: шаблон Proactor с boost.asio?)