Linux максимальное число процессов

как изменить максимальное количество процессов форка пользователем в linux

Всякий раз, когда я вхожу в оболочку, я получаю эту ошибку

Я не могу выполнить любую команду, которая использует fork() .

Я попытался ulimit -u как он не использует fork и вернул 35 . Каким-то образом мой максимальный процесс установлен на 35 .

Я хочу увеличить это, но я не знаю, где это сделать.

6 ответов 6

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

Если вы хотите сделать более постоянное изменение, вам нужно отредактировать либо /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?

как (если возможно) это значение может быть изменено?

16 ответов

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

Источник

Русские Блоги

Количество процессов и дескрипторов linux

Примечание: версия Linux CentOS7

оглавление

Единая концепция обработки и управления

Программа может открывать несколько объектов, а именно процессов;

Во время работы процесс будет открывать множество ресурсов, включая файл файла, сокет коммуникационного соединения, порт прослушивания и т. Д. Мы называем их коллективными дескрипторами. Все в Linux является файлом, поэтому, когда процесс открывает количество дескрипторов При превышении системного лимита мы получим предупреждение: слишком много открытых файлов.

Во-вторых, ограничения ресурсов Linux

1. Ограничения пользовательских ресурсов

В Bash есть команда ulimit, которая обеспечивает управление доступными ресурсами оболочки и процессами, запускаемыми оболочкой. В основном это количество открытых файловых дескрипторов, максимальное количество процессов пользователя, размер файла coredump и т. Д.

Конфигурацию ограничений ресурсов можно настроить в файле подконфигурации в /etc/security/limits.conf или /etc/security/limits.d/. Система сначала загружает limits.conf, а затем загружает каталог limits.d в алфавитном порядке. После загрузки файла конфигурации он перезапишет предыдущую конфигурацию. Формат конфигурации следующий:

soft — значение предупреждения, hard — максимальное значение, * означает соответствие всем пользователям

Просмотр ограничений пользовательских ресурсов для входа в текущую оболочку

2. ограничение ресурса обслуживания

Мы всегда упоминали оболочку выше, поэтому для тех пользователей, которые не вошли в систему через аутентификацию PAM, таких как mysql, nginx и т. Д., Вышеуказанная конфигурация не эффективна;

Поскольку в системе CentOS 7 / RHEL 7 вместо предыдущего SysV используется Systemd, область конфигурации файла /etc/security/limits.conf сокращается. Конфигурация в limits.conf применима только для аутентификации PAM. Ограничение ресурсов вошедшего в систему пользователя, оно не влияет на ограничение ресурсов службы systemd.

Его нужно настроить с помощью файлов /etc/systemd/system.conf и /etc/systemd/user.conf. Точно так же все файлы .conf в двух соответствующих каталогах /etc/systemd/system.conf.d/* .conf и /etc/systemd/user.conf.d/*.conf.

Среди них system.conf используется экземплярами системы, а user.conf — экземплярами пользователей. Для общих служб используйте конфигурацию в system.conf. Конфигурация в system.conf.d / *. Conf переопределит system.conf.

Формат конфигурации следующий:

= Тип ресурса слева, размер справа

Просмотр лимита ресурсов службы

Например, проверьте влияние конфигурации службы nginx:

3. Лимит системных ресурсов

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

Три, количество процессов ограничено

1. Ограничьте количество пользовательских процессов.

По умолчанию в /etc/security/limits.d/ есть файл подконфигурации 20-nproc.conf, который используется для установки максимального количества процессов для каждого пользователя.

Проверка /etc/security/limits.d/20-nproc.conf обнаружит, что пользователь root по умолчанию не ограничен, а максимальное количество обычных пользовательских процессов составляет 4096

Фактически, root и обычные пользователи по умолчанию используют значение # cat / proc / sys / kernel / threads-max / 2, что составляет половину количества системных потоков.

Установите максимальное количество процессов на пользователя

Примечание. Изменение файла конфигурации не повлияет на ограничение процесса для текущего пользователя, вошедшего в систему.

2. Лимит процесса обслуживания

Примечание: изменение файла конфигурации не изменит ограничение на количество процессов запущенной в данный момент службы, и ее необходимо перезапустить.

3. Общее количество процессов в системе.

Выше мы установили максимальное количество процессов, которые может открыть каждый пользователь, но это не контролирует общее количество процессов в системе (kernel.pid_max). Предполагая, что kernel.pid_max = 1000, максимальное количество пользовательских процессов пользователя, независимо от того, насколько велико заданное значение, Максимальное количество процессов, которые можно открыть, по-прежнему составляет 1000

Просмотрите глобальный метод pid_max:

Временно измените этот метод значения:

Следовательно, после завершения вышеуказанных операций значение максимального числа пользовательских процессов изменяется правильно.

Вышеуказанное действует только временно, оно будет недействительным после перезапуска машины, постоянный эффективный метод:

Добавьте kernel.pid_max = 65535 в /etc/sysctl.conf

Затем перезапустите машину.

В-четвертых, ограничение количества ручек

1. Ограничьте количество пользовательских дескрипторов

Лимит пользователя для входа, как упоминалось выше, можно настроить с помощью файла подконфигурации в /etc/security/limits.conf или /etc/security/limits.d/ следующим образом:

Примечание: изменение файла конфигурации не повлияет на ограничение дескриптора текущего пользователя, вошедшего в систему.

2. Предел обработки обслуживания

Примечание. Изменение файла конфигурации не приведет к изменению ограничения дескриптора запущенной в данный момент службы.

3. Общее количество системных дескрипторов.

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

Измените максимальное количество системных дескрипторов, метод следующий (действителен после настройки):

Просмотрите общее количество дескрипторов, используемых в настоящее время в системе:

Источник

Русские Блоги

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

команда ulimit для просмотра и изменения системных ограничений

Подробное объяснение команды ulimit

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

в /etc/security/limits.conf Определено в документе
Ограничения.

Параметры команды	описание	пример
-H	Установите жесткие ограничения ресурсов, после того, как набор не может быть увеличен.	ulimit-Hs 64; ограничивает жесткие ресурсы, размер стека потока равен 64 КБ.
-S	Установите ограничение мягких ресурсов, которое может быть увеличено после настройки, но не может превышать настройки жесткого ресурса.	ulimit-Sn 32; ограничение мягких ресурсов, 32 файловых дескриптора.
-a	Показать всю текущую информацию о лимите	ulimit-a; отображать всю текущую информацию о лимитах
-c	Размер самого большого файла ядра, в блоках	ulimit — c без ограничений, без ограничений на размер сгенерированного файла ядра
-d	Размер самого большого сегмента данных процесса, в килобайтах	ulimit -d неограничен, размер сегмента данных процесса не ограничен
-f	Максимальное количество файлов, которое может создать процесс, в блоках	ulimit — f 2048; ограничить максимальный размер файла, который может создать процесс, до 2048 блоков.
-l	Максимальный запираемый объем памяти, в килобайтах	ulimit — l 32; ограничить максимальный объем блокируемой памяти до 32 Кбайт
-m	Максимальный объем памяти в килобайтах	ulimit-m не ограничен, нет ограничений на максимальную память
-n	Максимальное количество файловых дескрипторов, которые могут быть открыты	ulimit-n 128; ограничение до 128 файловых дескрипторов
-p	Размер буфера трубы в килобайтах	ulimit — p 512; ограничить размер буфера конвейера до 512 Кбайт
-s	Размер стека потоков, в килобайтах	ulimit — s 512; ограничить размер стека потока до 512 Кбайт
-t	Максимальное время процессора в секундах	ulimit — t не ограничено; нет ограничений по максимальному времени загрузки процессора
-u	Максимальное количество процессов, доступных пользователям	ulimit-u 64; ограничение пользователей на использование до 64 процессов
-v	Максимально доступная виртуальная память процесса, в килобайтах	ulimit — v 200000; ограничение максимально доступной виртуальной памяти до 200000 Кбайт

Мы можем использовать ulimit -a для просмотра всех ограничений нашей системы.

Конечно, мы все знаем, что большинство настроек команды Linux временно действуют, а команда ulimit действует только для текущего терминала.

Если это должно быть постоянно эффективно, у нас есть два метода,

Один из них — написать команду для профиля и bashrc, что эквивалентно автоматическому изменению лимита при входе в систему.

Другой способ заключается в добавлении записи в /etc/security/limits.conf (для вступления в силу требуется перезапуск, а модуль ограничения используется при переходе в /etc/pam.d/).

Приложение к файлу Limits.conf

Формат изменения лимитов в /etc/security/limits.conf выглядит следующим образом

параметры	описание
domino	Имя пользователя или группы, начинающиеся с символа @, * означает всех пользователей
type	Установить на жесткий или мягкий
item	Укажите ресурс, который вы хотите ограничить. Такие как процессор, ядро ​​nproc или maxlogins
value	Соответствует

Максимальное количество процессов

Расчет максимального теоретического количества процессов в LINUX

• Каждый процесс должен занимать две записи в таблице описания глобального сегмента GDT.

Локальная таблица описания сегмента LDT каждого процесса существует как независимый сегмент.В глобальной таблице описания сегмента GDT должна быть запись, указывающая на начальный адрес сегмента и указывающая длину сегмента и другие параметры. В дополнение к вышесказанному каждый процесс также имеет структуру TSS (сегмент состояния задачи). Поэтому каждый процесс должен занимать две записи в глобальной таблице описания сегментов GDT.

Ширина сегмента битов, используемого в качестве нижнего индекса таблицы GDT в регистре сегментов, составляет 13 битов, поэтому может быть 2 1 3 = 8192 Описание предметов.

За исключением некоторых системных издержек (например, элементы 2 и 3 в GDT используются для сегмента кода и сегмента данных ядра, элементы 4 и 5 всегда используются для сегмента кода и сегмента данных текущего процесса, элемент 1 Всегда 0 и т. Д.), По-прежнему доступно 8180 записей, поэтому теоретически максимальное количество процессов в системе равно 8180 / 2 = 4090 。

Таким образом, теоретическое максимальное количество процессов в системе составляет 4090

Фактическое количество процессов, которые могут быть созданы в системе

Ядро Linux использует значение идентификации процесса (PID) для идентификации процесса, PID — это число, бит типа pid_t, на самом деле int

Для обеспечения совместимости со старыми версиями Unix или Linux максимальное значение PID по умолчанию установлено равным 32768 (максимальное значение short int).

Можно использовать cat /proc/sys/kernel/pid_max Для просмотра фактического значения количества процессов, которые могут быть созданы в системе

После установки, хотя мы установили жесткое ограничение и мягкое ограничение числа процессов создания пользователя 65535, мы не можем использовать для создания 65535 процессов

Нам также нужно установить параметр ядра kernel.pid_max в Linux. Этот параметр по умолчанию равен 32768.

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

Максимальное количество потоков

Максимальное количество потоков одного процесса в системе Linux имеет максимальное ограничение PTHREAD_THREADS_MAX

Этот предел может быть /usr/include/bits/local_lim.h Посмотреть в
Для linuxthreads это значение обычно составляет 1024, для nptl нет жесткого ограничения, ограничивается только системными ресурсами.

Ресурсы этой системы в основном представляют собой память, занятую стеком потоков. Используйте ulimit -s для просмотра размера стека потоков по умолчанию. В общем, это значение 8M=8192KB

Вы можете написать простой код, чтобы проверить, сколько потоков можно создать.

Эксперименты показывают, что в нашей системе (Ubuntu-14.04-LTS-64bit) на linuxthreads можно создать максимум 381 поток, после чего он вернется в EAGAIN.

Максимальное количество потоков, которое теоретически может создать отдельный процесс в Linux

В 32-битной системе можно использовать 381 поток. Это значение полностью согласуется с теорией, поскольку пользовательское пространство процесса в 32-битной Linux — это 3G, что составляет 3072M. 3072 M / 8 M = 384 Но на самом деле сегмент кода и сегмент данных также занимают некоторое пространство.Это значение должно быть округлено до 383, а затем вычтено из основного потока, чтобы получить 382.

Так почему же на linuxthreads есть одна нить? Это правильно, потому что linuxthreads также нуждается в потоке управления

Чтобы преодолеть ограничение памяти, есть два метода

использование ulimit -s 1024 Уменьшите размер стека по умолчанию

вызов pthread_create Время с pthread_attr_getstacksize Установить меньший размер стека

Следует отметить, что даже это не может нарушить жесткий предел 1024 потоков, если библиотека C не будет перекомпилирована

Максимальное количество открытых файлов

Максимальное количество файловых файловых дескрипторов системы

/ proc / sys / fs / file-max определяет общесистемное количество дескрипторов файлов, которые могут быть открыты всеми процессами (системный уровень, уровень ядра).

The value in file-max denotes the maximum number of file handles that the Linux kernel will allocate）.

Когда вы получаете сообщение об ошибке типа «Слишком много открытых файлов в системе», вы должны добавить это значение.

Для ядер 2.2 также необходимо учитывать inode-max. Как правило, inode-max устанавливается в 4 раза больше, чем file-max. Для ядер 2.4 и новее нет файла inode-max.

Посмотреть актуальное значение

Вы можете использовать cat / proc / sys / fs / file-max для просмотра количества дескрипторов файлов, которые могут быть открыты одним процессом в текущей системе.
186405

Настроить

• Постоянный: устанавливается в /etc/sysctl.conf

nr_open — максимальное количество файлов, которое может быть выделено одним процессом

Максимальное количество файловых дескрипторов, поддерживаемых ядром, то есть максимальное количество файловых дескрипторов, используемых процессом

the maximum number of files that can be opened by process。

Nofile обрабатывает максимальное количество дескрипторов открытых файлов

Посмотреть актуальное значение

Конечно, представление по умолчанию — это мягкое ограничение мягкого ограничения ресурса. Если вы хотите просмотреть максимальное количество открытых символов описания файла процесса, поддерживаемых аппаратным обеспечением системы, вы можете использовать ulimit -Hn

Настроить

по ulimit -Sn Установите мягкое ограничение максимального числа дескрипторов открытых файлов. Обратите внимание, что мягкое ограничение не может превышать жесткое ограничение (ulimit -Hn может просматривать жесткое ограничение)

Кроме того, ulimit -n по умолчанию просматривает мягкий предел, но ulimit -n 1800000 устанавливает мягкий и жесткий лимит одновременно.

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

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

Чтобы сделать изменение постоянным и эффективным, вам нужно установить его в /etc/security/limits.conf (требуется разрешение root), вы можете добавить следующие две строки, указывающие, что мягкое ограничение максимального числа дескрипторов открытых файлов для пользовательского канала составляет 1800000, жесткое ограничение 2000000. Для вступления в силу следующих настроек необходимо выйти и войти снова:

Еще одна вещь, которую следует отметить при установке жесткого предела nofile, заключается в том, что жесткий предел не может быть больше, чем / proc / sys / fs / nr_open. Если жесткий предел больше, чем nr_open, вы не сможете войти в систему после выхода из системы.

Значение nr_open можно изменить:

Связь между file-max, nr_open, onfile

Для ограничения максимального количества файлов, открытых пользователем, nofile, соответствующий limit.conf, будь то руководство пользователя или файл, является всего лишь предложением

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

Согласно руководству пользователя, «значения -1, неограниченный или бесконечность, указывающие на отсутствие ограничений», -1, неограниченный и бесконечность, все указывают на отсутствие ограничений

Однако, когда вы фактически установите nofile на это значение, вы обнаружите, что не можете войти в систему при перезапуске.

Видно, что у nofile есть верхний предел и тест ulimit:

bash: ulimit: открытые файлы: невозможно изменить ограничение: операция запрещена

Напишите простой цикл for, чтобы получить:

Затем выполните ulimit -n, и вы увидите, что 1048576 является максимальным значением nofile, но почему это значение?

1024 ∗ 1024 = 1048576 Конечно, яиц мало используют.

После повторной трассировки мы обнаружим, что это значение фактически определяется параметром ядра nr_open:

На этом этапе мы поговорим о nr_open и file-max. Когда дело доходит до установки максимального количества файлов в Интернете, в некоторых публикациях также иногда говорится, что file-max необходимо изменить. Буквально, file-max действительно соответствует максимальному количеству файлов. Объяснение двух в документации ядра Linux:

• file-max：
  The value in file-max denotes the maximum number of file-
  handles that the Linux kernel will allocate. When you get lots
  of error messages about running out of file handles, you might
  want to increase this limit

Выполните: grep -r MemTotal / proc / meminfo | awk ‘’, вы можете видеть, что это похоже на file-max;

• nr_open:
  This denotes the maximum number of file-handles a process can
  allocate. Default value is 1024*1024 (1048576) which should be
  enough for most machines. Actual limit depends on RLIMIT_NOFILE
  resource limit.

файловые дескрипторы (то есть файловые дескрипторы), тогда в UNIX / LINUX мы более подвержены файловому дескриптору (FD, т.е. файловые дескрипторы), кажется, что файловый дескриптор в Windows — это материал, похожий на файл-дискриптор Но мы говорим о Linux, а затем Google, мы можем быть точными в разнице между этими двумя понятиями на языке c,

Согласно их обсуждению, дескриптор файла должен быть объектом высокого уровня, который вызывается с использованием таких функций, как fopen и fread, а FD является базовым объектом, который можно вызывать с помощью таких функций, как open и read.

На этом этапе мы должны сделать грубый вывод: File-max — это максимальное количество файлов, которое может быть выделено ядром, а nr_open — это максимальное количество файлов, которые могут быть выделены одним процессом, поэтому, когда мы используем ulimit или limit.conf для установки, если Если вы хотите превысить значение по умолчанию 1048576, вам нужно увеличить значение nr_open (sysctl -w fs.nr_open = 100000000 или записать его непосредственно в файл sysctl.conf). Конечно, должно хватить максимального числа открытых файловых дескрипторов одного уровня на уровне миллиона. ,

Количество файловых дескрипторов, открытых всеми процессами, не может превышать / proc / sys / fs / file-max

Количество файловых дескрипторов, открытых одним процессом, не может превышать мягкое ограничение nofile в пользовательском ограничении

Мягкий предел Nofile не может превышать его жесткий предел

жесткий предел nofile не может превышать / proc / sys / fs / nr_open

другое

Следующее содержание воспроизводится с

Основное отличие ядра 2.4 от ядра 2.6

В типичной системе с ядром 2.4 (AS3 / RH9) потоки реализованы с облегченными процессами. Каждый поток занимает идентификатор процесса. В программе сервера, если он сталкивается с доступом с высокой скоростью кликов, он вызывает переполнение таблицы процессов. Чтобы поддерживать переполненную таблицу процессов, система будет периодически приостанавливать обслуживание, и ядро ​​2.6 не будет вызывать проблему переполнения таблицы процессов из-за создания и уничтожения большого количества потоков.

Стек потока должен быть освобожден, когда поток заканчивается

Другими словами, функция потока должна вызывать pthread_exit () для завершения, иначе она не будет освобождена до тех пор, пока не прекратится выполнение основной функции процесса, особенно в среде ядра 2.6, скорость создания потока будет высокой, а память случайно израсходована. Это среда ядра 2.4. Потому что ядро ​​2.4 создает процессы, а скорость создания потоков на несколько порядков ниже, чем в ядре 2.6. В частности, на 64-разрядных процессорах скорость создания потоков в ядре 2.6 еще выше, если он слишком быстрый, лучше добавить usleep (), чтобы сделать паузу на некоторое время.

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

Только те программы, которые не нуждаются в мьютексах, могут максимально использовать преимущества потокового программирования, в противном случае оно будет только медленнее. Ядро 2.6 является преимущественным ядром, и вероятность разделения конфликтов между потоками намного выше, чем в среде ядра 2.4. Обратите внимание на безопасность потоков. В противном случае даже один ЦП может привести к несинхронизации некоторой необъяснимой памяти (кэш-память ЦП и содержимое основной памяти несовместимы). Новый ЦП Intel использует архитектуру NUMA для повышения производительности. Вам следует обратить внимание, чтобы избежать недостатков в программировании потоков.

Максимальное количество одновременных потоков и памяти для однопроцессного сервера

Очень интересно, по умолчанию параметр ulimit, заголовочный файл ядра не изменяется
Память AS3 512M до 1000 одновременных непрерывных соединений
CentOS4.3 512M памяти до 300 одновременных непрерывных соединений
Кажется, что CentOS не так хорош, как AS3. Основная причина здесь заключается в конфигурации ulimit. Конфигурация двух систем по умолчанию сильно отличается. Если вы хотите сохранить больше потоков для одновременного получения соединений в одном процессе, вы должны минимизировать параметр ulimit -s и вставить больше. Модуль памяти, параллелизм 2000 на однопроцессном сервере не сложен. Предел по умолчанию для POSIX составляет 64 потока на процесс, но NTPL не является чистым POSIX. Не обращайте внимания на это ограничение. Реальное ограничение в ядре 2.6 — это количество слотов для модулей памяти ( Может быть, еще есть деньги на покупку памяти)
В программировании последних нескольких дней я заметил, что максимальное количество потоков, созданных одним процессом ядра 2.6 на 32-битной платформе x86 = верхний предел / стек VIRT, который не имеет никакого отношения к общему объему памяти. Верхний предел по умолчанию VIRT для 32-битных систем x86 равен 3G Режим 3G + 1G), размер стека по умолчанию составляет 10240 КБ, поэтому верхний предел по умолчанию для потока создания одного процесса равен 300 (3072M / 10240K). Изменение стека до 1024K с помощью ulimit -s увеличит верхний предел примерно до 3050. У меня под рукой нет 64-битной системы, и я не знаю, создает ли ядро ​​2.6 ограничение потока для 64-битного одиночного процесса (на самом деле я слишком ленив, чтобы установить fc4_x86_64 на компьютер моего коллеги).
Несколько дней назад я купил дешевую 64-разрядную систему x86 (64-разрядная материнская плата Saiyang + Miscellaneous 915), установил версию CentOS4.3 для x86_64, запустил следующую небольшую программу, и в результате получилось: в ulimit -s В случае 4096 максимальное количество потоков в одном процессе составляет чуть больше 16000, используйте top, чтобы увидеть
Верхний предел VIRT составляет 64G, что составляет 36 бит. Результат cat / proc / cpuinfo: размеры адресов: 36-битная физическая, 48-битная виртуальная, отличная от стандартной 64-битной системы, которую я себе представлял, я всегда думал о пространстве памяти 64-битных систем Также 64-битный

Примечание 1

Вентиляторы BSD в устройстве использовали ноутбук AMD64 для запуска небольшой программы для проверки скорости создания потока (phread_detach () сразу после создания потока, а затем pthread_exit (), всего 1 миллион потоков). Тот же исходный код OpenBSD был в 3 раза быстрее, чем FreeBSD Когда OpenBSD сошел с ума?

Источник