Каковы ограничения потоков при работе в Linux по сравнению с процессами для приложений, связанных с сетью/IO?

Я слышал, что под linux на многоядерном сервере невозможно достичь максимальной производительности, если у вас всего 1 процесс, но несколько потоков, потому что Linux имеет некоторые ограничения на IO, так что 1 процесс с 8 потоками на 8-ядерном сервер может быть медленнее 8 процессов.

Любые комментарии? Существуют ли другие ограничения, которые могут замедлить работу приложений? Приложения представляют собой сетевое приложение С++, обслуживающее 100 клиентов, с некоторым диском IO.

Обновление: Я обеспокоен тем, что есть еще несколько проблем, связанных с IO, отличных от блокировки, которую я реализую самостоятельно... Не существует ли проблем, связанных с одновременным сетевым/дисковым IO в нескольких потоках?

Ответ 1

Недостатки потоков

Темы:

Сериализовать операции с памятью. Это ядро, и в свою очередь MMU должен обслуживать такие операции, как mmap(), которые выполняют распределение страниц.
Поделитесь той же файловой дескрипторной таблицей. Блокировка включает в себя внесение изменений и выполнение поиска в этой таблице, в которой хранятся такие вещи, как смещения файлов и другие флаги. Каждый системный вызов, который использует эту таблицу, например open(), accept(), fcntl(), должен блокировать ее для перевода fd во внутренний дескриптор файла и при внесении изменений.
Поделитесь некоторыми атрибутами планирования. Процессы постоянно оцениваются для определения нагрузки, которую они загружают в систему, и соответственно планируются. Множество потоков подразумевает более высокую нагрузку на процессор, что обычно не нравится планировщику, и увеличивает время отклика на события для этого процесса (например, считывание входящих данных в сокете).
Может передавать некоторые записываемые данные. Любая память, написанная несколькими потоками (особенно медленная, если она требует фантазии блокировки), будет генерировать все виды конфликтов и конфликтов конфликтов. Например, операции кучи, такие как malloc() и free(), работают с глобальной структурой данных (что в какой-то степени можно обойти). Существуют и другие глобальные структуры.
Поделите учетные данные, это может быть проблемой для процессов типа обслуживания.
Обработка сигналов общего доступа, они будут прерывать весь процесс во время обработки.

Процессы или потоки?

Если вы хотите облегчить отладку, используйте потоки.
Если вы используете Windows, используйте потоки. (Процессы чрезвычайно тяжелы в Windows).
Если стабильность является серьезной проблемой, попробуйте использовать процессы. (Один SIGSEGV/PIPE - это все, что требуется...).
Если потоки недоступны, используйте процессы. (Не так часто, но это произошло).
Если ваши потоки совместно используют ресурсы, которые нельзя использовать из нескольких процессов, используйте потоки. (Или предоставить механизм IPC, позволяющий связываться с потоком "владельца" ресурса).
Если вы используете ресурсы, доступные только по принципу "один за процессом" (и каждый из них для каждого контекста), очевидно, используйте процессы.
Если ваши контексты обработки не имеют абсолютно ничего (например, сервер сокетов, который порождает и забывает подключения, как он accept() их), а ЦП является узким местом, используют процессы и однопоточные промежутки времени (которые лишены всех видов интенсивная блокировка, например, на куче и в других местах).
Одно из самых больших различий между потоками и процессами: Threads использует программные конструкции для защиты структур данных, процессы используют аппаратное обеспечение (что значительно быстрее).

Ссылки

Ответ 2

это действительно не имеет никакого значения, но, вероятно, о дизайне.

Для многопроцессорного приложения может потребоваться меньше блокировки, но может использовать больше памяти. Обмен данными между процессами может быть сложнее.

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

Это зависит от того, насколько зависимы клиенты. Я обычно рекомендую простейшее решение.