Linux максимальное количество процессов
Обновлено: 07.07.2024
Как известно, mongodb создает новый поток для каждого клиентского соединения, и раньше это работало нормально. Я не знаю почему, но MongoDB не может создать более 975 соединений на хосте как непривилегированный пользователь (он работает под пользователем mongod). Но когда я запускаю его как пользователь root, он может обрабатывать до 20000 подключений (внутреннее ограничение mongodb). Но дальнейшие исследования показывают, что проблема не в сервере MongoDB, а в самом Linux.
Я нашел простую программу, которая проверяет максимальное количество соединений:
И повторяемость повторяется снова, как пользователь root, я могу создать около 32 тыс. Потоков, а непривилегированный пользователь (mongod или ec2-user) - около 1000.
Это ограничение для пользователя root:
Это ulimit для пользователя mongod:
SELinux отключен. Не знаю, как решить эту странную проблему . Возможно, кто-то делает?
Ваша проблема - это max user processes предел.
Со getrlimit(2) страницы руководства :
RLIMIT_NPROC Максимальное количество процессов (или, точнее, в Linux, потоков), которое может быть создано для реального идентификатора пользователя вызывающего процесса. При fork(2) достижении этого предела происходит сбой с ошибкой EAGAIN .
EAGAIN Недостаточно ресурсов для создания другого потока или системное ограничение на количество потоков. Последний случай может происходить двумя способами: достигнут RLIMIT_NPROC предел мягкого ресурса (установленный через setrlimit(2) ), который ограничивает количество процессов для реального идентификатора пользователя; или /proc/sys/kernel/threads-max был достигнут общесистемный лимит ядра на количество потоков .
Увеличьте этот лимит для своего пользователя, и он сможет создавать больше потоков, пока он не достигнет других лимитов ресурсов.
Или просто исчерпание ресурсов - для стека 1 МБ и потоков 20 КБ вам потребуется много оперативной памяти.
Смотрите также NPTL caps максимальные темы на 65528? : /proc/sys/vm/max_map_count может стать проблемой в какой-то момент.
Побочный момент: вы должны использовать -pthread вместо -lpthread . Смотрите gcc - значение флага -pthread при компиляции .
Мы столкнулись с этой проблемой, когда проблемы с соединением от клиента mongo (java) прерываются (кажется, сетью AWS). Если для TCP_KEEPALIVE установлено значение 7200 (2 часа), соединения в пулах подключений будут создаваться в течение этого 2-часового окна, и mongod умирает, когда он достигает 975 соединений.
Контрольный список для производства монго предполагает, что keepalive гораздо меньше (5 минут); настройка, которая также поможет вам избежать ограничения соединения.
Какое максимальное количество потоков может быть создано процессом в Linux?
Как (если возможно) можно изменить это значение?
Ответ 1
В Linux нет отдельного ограничения потоков для каждого процесса, только ограничение на общее количество процессов в системе (потоки — это, по сути, просто процессы с общим адресным пространством в Linux), которые вы можете просмотреть следующим образом:
cat /proc/sys/kernel/threads-max
По умолчанию это количество страниц памяти/4. Это значение можно увеличить так:
echo 100000 > /proc/sys/kernel/threads-max
Также существует ограничение на количество процессов (и, следовательно, потоков), которые может создать один пользователь.
Ответ 2
НЕПРАВИЛЬНО утверждать, что в LINUX нет отдельных потоков для каждого процесса.
Linux косвенно реализует максимальное количество потоков на процесс .
number of threads = total virtual memory / (stack size*1024*1024)
Таким образом, количество потоков на процесс можно увеличить, увеличив общую виртуальную память или уменьшив размер стека. Но слишком большое уменьшение размера стека может привести к сбою кода из-за переполнения стека, в то время как максимальная виртуальная память равна размеру памяти подкачки.
Общая виртуальная память: ulimit -v (по умолчанию не ограничено, поэтому вам нужно увеличить память подкачки, чтобы увеличить это значение) .
Общий размер стека: ulimit -s (по умолчанию 8 М б ) .
Команда для увеличения этих значений:
ulimit -s newvalue
ulimit -v newvalue
* Замените новое значение значением, которое вы хотите установить в качестве ограничения.
Ответ 3
На практике предел обычно определяется размером стека. Если каждый поток получает стек размером 1 М б , тогда у вас в 32-разрядной системе адресное пространство закончится после 3000 потоков (при условии, что последний Г б зарезервирован для ядра).
Рано или поздно вы получите слишком много накладных расходов на переключение контекста, слишком много накладных расходов в планировщике и т. д. (Создание большого количества потоков создает много накладных расходов. Но множество потоков с реальной работой тормозит производительность, поскольку они борются за доступное время процессора) .
Ответ 4
Linux не использует виртуальную память для вычисления максимального количества потоков, а только физическую память, установленную в системе.
max_threads = totalram_pages / (8 * 8192 / 4096);
ядро/fork.c
/* Максимальное количество потоков по умолчанию установлено в безопасное значение.
* значение структуры потоков могут занимать не более половины памяти.
*/
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
Таким образом, максимальный поток различается для каждой системы, потому что установленная оперативная память может быть разного размера, поэтому Linux не нужно увеличивать виртуальную память, потому что на 32-битной версии у нас есть 3 Г б для пользовательского пространства и 1 Г б — для ядра, на 64-битной версии мы получили 128 Т б виртуальной памяти, что и происходит в Solaris. Если вы хотите увеличить виртуальную память, вам нужно добавить объем подкачки.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Я не могу выполнить любую команду, которая использует fork() .
Я попытался ulimit -u как он не использует fork и вернул 35 . Каким-то образом мой максимальный процесс установлен на 35 .
Я хочу увеличить это, но я не знаю, где это сделать.
Если вы хотите изменить ограничение только для этой оболочки, вы можете запустить:
Если вы хотите сделать более постоянное изменение, вам нужно отредактировать либо /etc/limits.conf либо /etc/security/limits.conf (в зависимости от вашего дистрибутива Linux) и добавить следующие строки:
Замените username фактическим именем пользователя
Вместо имени пользователя также можно использовать имя группы, если вы добавите к нему префикс @ . Если вы используете * это будет по умолчанию для всех пользователей
Это можно изменить в /etc/security/limits.conf . Ищите строки вида:
Эти строки ограничивают username пользователя user до 25 процессов и пользователей в группе groupname до 100 процессов. Вам понадобятся права суперпользователя на компьютере.
Вот несколько идей:
Если ваш limits.conf пуст, grep -l ulimit /etc/* $HOME/.* 2> /dev/null чтобы проверить, установил ли кто-то ulimit где-нибудь, и удалите его.
После редактирования limit.conf все, что вам нужно сделать, это выйти и снова войти в систему, чтобы вступить в силу.
Чтобы получить процесс, используйте exec . Попробуйте, например, exec sudo su стать пользователем root.
Есть еще одна возможность, что конфигурация для "noproc" не работает во время настройки в /etc/security/limits.conf.
Есть еще один файл, который переопределяет вашу конфигурацию /etc/security/limits.d/90-nproc.conf.
Здесь * config переопределит все, что вы установили в предыдущем файле конфигурации. Так что в идеале вы настраиваете свои настройки в этом файле.
Этого должно быть достаточно, чтобы (пере) установить ulimit, не нужно менять конфигурацию (не говоря уже о общесистемной конфигурации в /etc ). И 35 процессов должно быть много, что-то не так с процессом входа в OP.
В терминале выполните ps -au , которая должна показать все процессы, работающие от вашего имени, проверьте список (или опубликуйте его здесь), чтобы увидеть, происходит ли что-то странное.
Как уже упоминалось, посмотрите на limits.conf . Когда вы входите в Gnome, KDE или любой другой графический интерфейс, вероятно, у вас уже запущено более 35 процессов.
Выйдите из GUI и переключитесь на VT, например, с помощью Ctl Alt F1 , и войдите без GUI.
какое максимальное количество потоков может быть создано процессом под Linux?
как (если возможно) это значение может быть изменено?
Linux не имеет отдельных потоков на ограничение процесса, просто ограничение на общее количество процессов в системе (потоки-это, по сути, просто процессы с общим адресным пространством в Linux), которые вы можете просмотреть следующим образом:
по умолчанию используется количество страниц памяти/4. Вы можете увеличить это как:
существует также ограничение на количество процессов (и, следовательно, потоков), которые может создать один пользователь, см. ulimit/getrlimit для получения подробной информации о эти рамки.
неверно говорить, что LINUX не имеет отдельных потоков на ограничение процесса.
Linux реализует максимальное количество потоков на процесс косвенно!!
таким образом, количество потоков на процесс может быть увеличено за счет увеличения общей виртуальной памяти или уменьшения размера стека. Но слишком большое уменьшение размера стека может привести к сбою кода из-за переполнения стека, в то время как максимальная виртуальная память равна swap память.
проверьте машину:
Общая Виртуальная Память: ulimit -v (по умолчанию не ограничено, поэтому вам нужно увеличить память подкачки увеличить это)
Общий Размер Стека: ulimit -s (по умолчанию 8 МБ)
*замените новое значение значением, которое вы хотите поместить как предел.
ссылки:
на практике предел обычно определяется пространством стека. Если каждый поток получает стек 1 МБ (я не могу вспомнить, является ли это значением по умолчанию в Linux), то у 32-разрядной системы закончится адресное пространство после 3000 потоков (при условии, что последний ГБ зарезервирован для ядра).
однако вы, скорее всего, испытаете ужасную производительность, если будете использовать более нескольких десятков потоков. Рано или поздно вы получаете слишком много накладных расходов на переключение контекста, слишком много накладных расходов в планировщик и так далее. (Создание большого количества потоков делает немного больше, чем съедает много памяти. Но много потоков с actual работа делать будет замедлять вас, как они борются за доступное время процессора)
Что вы делаете, когда этот предел будет еще актуальна?
правильные потоки 100k в linux:
2018 обновление от @Thomas, на системах systemd:
Linux не использует виртуальную память для вычисления максимума потока, но физический ОЗУ, установленный в системе
таким образом, поток max отличается между каждой системой, потому что установленный ОЗУ может быть разных размеров, я знаю, что Linux не нужно увеличивать виртуальная память, потому что на 32 бит мы получили 3 ГБ для пользовательского пространства и 1 ГБ для ядра, на 64 бит мы получили 128 ТБ виртуальной памяти, что происходит на Solaris, если вы хотите увеличить виртуальную память, вам нужно добавить пространство подкачки.
чтобы получить это:
ограничение количества потоков:
как это вычисляется:
и: x86_64 размер страницы (PAGE_SIZE) - 4K; Как и все другие модели, архитектуру x86_64 имеет стек ядра для каждого активного потока. Эти стеки потоков THREAD_SIZE (2*PAGE_SIZE) большие;
таким образом, на самом деле число не связано с ограничением размера стека памяти потока ( ulimit -s ).
P. S: ограничение стога памяти потока 10M внутри моя RHEL VM, а для памяти 1.5 G Эта VM может позволить себе только 150 потоков?
Это, вероятно, не должно иметь значения. Вы получите гораздо лучшую производительность, разрабатывая свой алгоритм для использования фиксированного количества потоков (например, 4 или 8, Если у вас есть 4 или 8 процессоров). Вы можете сделать это с рабочими очередями, асинхронным вводом-выводом или чем-то вроде libevent.
использовать nbio неблокирующий ввод-вывод библиотека или что-то еще, если вам нужно больше потоков для выполнения вызовов ввода-вывода, которые блокируют
проверьте размер стека на поток с помощью ulimit, в моем случае Redhat Linux 2.6:
каждый из потоков получит этот объем памяти (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
Читайте также: