Ограничение потока в Unix, прежде чем влиять на производительность

Question

У меня есть несколько вопросов относительно тем:

1. Какое максимальное количество потоков разрешено для процесса, прежде чем оно снижает производительность приложения?
2. Если есть предел, как это можно изменить?
3. Существует ли идеальное количество потоков, которое должно выполняться в многопоточном приложении? Если это зависит от того, что делает приложение, можете привести пример?
4. Какие факторы следует учитывать, влияющие на ограничение производительности / потока?

Answer 1

На самом деле это сложный набор вопросов, на которые нет абсолютных ответов, но следующие приличия должны служить достойными приближениями:

1. Это функция поведения вашего приложения и среды выполнения, и ее можно определить только экспериментально. Обычно существует порог, после которого ваша производительность фактически снижается при увеличении количества потоков.

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

3. Не существует общего "идеального" количества потоков, но вы можете иногда найти оптимальное количество потоков для приложения в конкретной среде выполнения. Обычно это делается экспериментированием и составлением графиков результатов тестов, варьируя следующее:

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

4. Существует множество факторов, влияющих на пределы потоков, но наиболее распространенными из них являются:

   • Использование памяти для каждого потока (чем больше памяти использует каждый поток, тем меньше потоков вы можете создать)
   • Стоимость переключения контекста (чем больше потоков вы используете, тем больше процессорного времени затрачивается на переключение).
   • Блокировка конкуренции (если вы полагаетесь на большое количество крупнозернистых блокировок, увеличение числа потоков просто увеличивает конкуренцию.)
   • Потоковая модель ОС (Как она управляет потоками? Сколько стоит каждый поток?)
   • Поточная модель языковой среды выполнения. (Сопрограммы, зеленые потоки, потоки ОС, искры и т. Д.)
   • Аппаратное обеспечение. (Сколько процессоров / ядер? Является ли оно гиперпоточным? Осуществляет ли балансировка нагрузки в операционной системе соответствующим образом и т. Д.)
   • Etc. (их гораздо больше, но перечисленные выше являются наиболее важными.)

Answer 2

Пока потоки предназначены для выполнения отдельных задач, проблем не так много. Однако проблема начинается, когда эти потоки пересекают ресурсы, когда должен быть реализован механизм блокировки.

Answer 3

Пока у вас никогда не будет больше потоков, использующих процессорное время, чем у ядер, у вас будет оптимальная производительность, но тогда, как только вам придется ждать ввода / вывода, будут неиспользованные циклы процессора, так что вы можете захотеть Профилируйте ваши приложения и смотрите, сколько времени ожидания он тратит на максимальную загрузку ЦП и какую часть ожидает ОЗУ, жесткий диск, сеть и другие операции ввода-вывода, в общем, если вы ожидаете ввода-вывода, у вас может быть еще 1 поток При условии, что вы в основном связаны с процессором).

Для жесткого и абсолютного предела. Проверьте PTHREAD_THREADS_MAX в limit.h. Это может быть то, что вы ищете. Может быть POSIX_THREAD_MAX в некоторых системах.

Answer 4

1. Ничего не исправлено: все зависит от того, что они делают. Иногда добавление большего количества потоков для асинхронного ввода-вывода может повысить производительность другого потока без каких-либо побочных эффектов.
2. Вероятно, это исправлено во время компиляции.
3. Нет, это решение архитектуры процесса. Но наличие хотя бы одного потока слушателя-планировщика помимо одного или нескольких потоков, выполняющих тяжелую работу, предполагает, что число обычно должно быть не менее двух.
4. Почти наверняка, ваша способность действительно понять, что происходит. Потоковый код запирается легко и самым неожиданным образом: сложно убедиться, что в коде нет гонок / тупиков. Изучите различные способы обработки параллелизма, такие как shared-nothing (ср. Эрланг).

Answer 5

Ответ на ваши вопросы 1, 3 и 4 «зависит от приложения». В зависимости от того, что делают ваши потоки, вам может потребоваться другое число, чтобы максимизировать эффективность вашего приложения.

Что касается вопроса 2, то здесь почти наверняка есть предел, и это не обязательно то, что вы можете легко изменить. Количество одновременных потоков может быть ограничено для каждого пользователя, или может быть максимальное количество разрешенных потоков в ядре.

Answer 6

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