LINUX.ORG.RU

Что может блокировать создание тредов выше 12000 если все лимиты задраны по максимуму?

 ,


1

1

Подскажите в каком направлении копать?

Pthread_create() возвращает EAGAIN

Доступной рамы — over 32GB

Стек ограничен — 256 КБ.

/etc/sysctl.conf:

kernel.threads-max = 999999
vm.max_map_count=1999999
kernel.pid_max = 4194303

/etc/systemd/system.conf:

DefaultTasksMax=unlimited

/etc/systemd/logind.conf:

UserTasksMax=999999

/etc/security/limits.conf:

*         hard    nproc      500000
*         soft    nproc      500000
*         hard    nofile      500000
*         soft    nofile      500000
*         hard    sigpending  257543
*         soft    sigpending  257543
★★★★★

Последнее исправление: cvv (всего исправлений: 2)

Какие хоть лимиты-то задраны расскажи, откуда знать может ты там задрал нерелевантное и даже не погуглил.

anonymous
()
  1. Проверяй что стек реально 256к, выглядит так, как будто ты упираешься в лимит адресного пространства: 32 000 000 000 / 12 000 = 2.5 метра, если у тебя стек 2 метра, а остальное - другие процессы - то реально уперся.
  2. проверяй количество пидов, может в них попячился.
  3. смотри исходники pthread_create, они доступны, это тебе не черный ящик с шиндой.
PPP328 ★★★★★
()

В kernel/fork.c посмотри все EAGAIN и проверь, что на них не наступаешь.

Ещё можно тупо systemtap натравить, чтобы он call graph напечатал: https://www.sourceware.org/systemtap/examples/#general/para-callgraph.stp Мне когда неохота в незнакомой части ядра ковыряться, я им быстренько нахожу.

mv ★★★★★
()
Ответ на: комментарий от menangen

Эм, а зачем тебе свыше 12000 тредов в одной программе?)

В EMCшную бытность один древний кусок кода работал на проприетарной юниксоподобной операционке без юзерспейса (только кернель мод) на древних интеловских процах, где глубоких оптимизаций в пайплайне ещё не было, так что контекст свич с одного кернельного треда на другой был весьма дёшев. Они использовали треды, как зелёные. Потом наступил 2013, новые интелы, код тот в юзерспейсе в линуксе заработал, нагрузки решили отмасштабировать увеличением кол-ва тредов, в итоге тредов стало где-то тыщ 16, ЕМНИП.

Десятки патчей на ядро накладывали, чтобы это шевелилось, там даже у шедулера проблемы были их в адекватное время перебирать.

А ещё в юзерспейсе можно было preemption запретить, установив один лишь бит в памяти, ибо код не был к preemptive модели готов, а кернельщики были лучше, чем товарищи, тот код написавший.

mv ★★★★★
()
Последнее исправление: mv (всего исправлений: 2)
Ответ на: комментарий от menangen

Ну требуется запустить г-но мамонта «как есть». Переписывать будем когда то в будущем.

cvv ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Отредактировал исходное сообщение

cvv ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Уже пользовался — не достаточно

cvv ★★★★★
() автор топика
Ответ на: комментарий от cvv

Поди с солярки перенесли на линукс? :)

dave ★★★★★
()

Вобщем, установили чистую убунту, применили настройки описанные в начале треда и на этом 20к удачно проскочили. Сейчас застряли на 28к, но по какой-то другой причине.

cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 1)
Ответ на: комментарий от deep-purple

нет, у меня с фряхой не сложились отношения.

cvv ★★★★★
() автор топика

Pthreads транслирует системное ENOMEM в EAGAIN. В остальном говорить что-то конкретное не получится без инфы о фактических показателях системы под нагрузкой.

byko3y ★★★★
()
Ответ на: комментарий от cvv

Pthread_create это не системный вызов. Запустить под strace -f -e trace=clone,mmap, чтобы понять, какой системный вызов фейлит. Это либо mmap, которым стек для потока выделяется в адресном пространстве процесса, либо clone, которым lwp создаётся.

iliyap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.