- limits.conf и лимиты потребления ресурсов для пользователей в Linux
- ulimit в Linux и ограничение ресурсов для пользователя
- Русские Блоги
- Количество процессов и дескрипторов linux
- Единая концепция обработки и управления
- Во-вторых, ограничения ресурсов Linux
- 1. Ограничения пользовательских ресурсов
- 2. ограничение ресурса обслуживания
- 3. Лимит системных ресурсов
- Три, количество процессов ограничено
- 1. Ограничьте количество пользовательских процессов.
- 2. Лимит процесса обслуживания
- 3. Общее количество процессов в системе.
- В-четвертых, ограничение количества ручек
- 1. Ограничьте количество пользовательских дескрипторов
- 2. Предел обработки обслуживания
- 3. Общее количество системных дескрипторов.
- Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- Re: Лимит процессов по количеству для пользователя
- системные настройки высоконагруженного сервера
- limits.conf
- sysctl.conf
- Заключение
limits.conf и лимиты потребления ресурсов для пользователей в Linux
Прежде всего, как выяснить процессы каких пользователей потребляют больше всего ресурсов CPU оперативной памяти.
Для текущего момента посмотреть процессы можно при помощи утилиты ps
ps aux —sort=%cpu | grep -v ‘root’ | head -n 35
ps aux —sort=%mem | grep -v ‘root’ | head -n 35
Команды выведут сортированные списки процессов в одной из колонок каждого списка будет указано имя пользователя. Процессы, запущенные от имени root показываться не будут и выведутся только 35 самых активных процессов.
Подобным образом статистику посмотреть не удасться, например, для веб-сервера с mod_php, однаако в большинстве случаев это как раз та информация, которая нужна для того чтобы выбрать пользователей для которых нужно предусмотреть ограничения.
Ограничения нужны на нагруженных серверах, они существует у каждого хостинг провайдера.
Лимитировать количество процессов можно используя механизм ядра cgroups — на практике проще всего установить ограничения отредактировав файл /etc/security/limits.conf и перезагрузив сервер.
Изменять /etc/security/limits.conf может только пользователь root или другой пользователь работающий из под sudo.
Файл хорошо задокументирован, вся необходимая информация находится в нем в комментариях
В общем виде любое правило выглядит так:
domain — это пользователь или группа, для которых лимитируем ресурсы
type — тип ограничения: soft или hard, ограничение soft может быть переопределено пользователем.
item — ресурс, который ограничиваем — обычно это cpu (в минутах) или as — максимальное количество оперативной памяти (в Кб); также можно задать nice level, который не сможет быть превышен процессами пользователя/группы (минимум 20, максимум -19); здесь же можно задать chroot (только для debian)
item — само численное значение
Как уже упоминалось — для того чтобы изменения вступили в силу нужна перезагрузка.
ulimit в Linux и ограничение ресурсов для пользователя
Soft лимиты пользователь может переопределить используя ulimit
Выполнение команды с аргументом -a выведет актуальные ограничения
ulimit -as 1500000
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 14685
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14685
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
Ключи из вывода можно брать и использовать в командах, которые будут задавать ограничения для текущей терминальной сессии.
Дополнительно следует указывать тип ограничения:
-H — hard
-S — soft
Если не указывать ничего лимиты будут заданы жестко. hard здесь можно задать для текущего пользователя даже без прав root, но изменения не сохранятся после перезагрузки и чтобы ограничения были установлены постоянно нужно редактировать файл, который был рассмотрен ранее.
Создадим ограничение по оперативной памяти в 1500 Мб для пользователя
Выполнив ulimit -Hm сейчас можно увидеть, что ограничение установлено. Получить ту же информацию можно просмотрев лимиты для процесса
Можно указывать идентификатор любого процесса, запущенного от имени пользователя, для которого задали ограничение по памяти
Источник
Русские Блоги
Количество процессов и дескрипторов 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. Общее количество системных дескрипторов.
Количество процессов, которые могут быть открыты каждым пользователем, и количество дескрипторов, которые могут быть открыты каждым процессом, указаны выше; есть также файл, который устанавливает общее количество дескрипторов, которые могут быть открыты всеми процессами в системе, то есть этот параметр является системным.
Измените максимальное количество системных дескрипторов, метод следующий (действителен после настройки):
Просмотрите общее количество дескрипторов, используемых в настоящее время в системе:
Источник
Лимит процессов по количеству для пользователя
Для ограничения количества процессов для пользователя надо патч ставить на ядро, или это можно сделать через /etc/login.conf ?
где-то ранее видел такое, вроде в /etc/login.conf, но теперь начал искать, никак не могу найти.
может кто сталкивался с этим.
спасибо.
Re: Лимит процессов по количеству для пользователя
Можно использовать PAM. Модуль называется pam_limits. Копай мануал на предмет опции nproc.
Re: Лимит процессов по количеству для пользователя
ulimit -u колво_процессов
Re: Лимит процессов по количеству для пользователя
Re: Лимит процессов по количеству для пользователя
Re: Лимит процессов по количеству для пользователя
дистр — слака 9.0
пытался понять кто использует файл /etc/security/limits.conf в АСП 10.0, но так и не понял.
пытался найти маны на limits.conf и похожее — бестолку, ничего путного.
этот файл (/etc/security/limits.conf) просто то что нужно. вот только кто его использует ((
Re: Лимит процессов по количеству для пользователя
> пытался понять кто использует файл /etc/security/limits.conf
Re: Лимит процессов по количеству для пользователя
А Slackware нет PAM.
Re: Лимит процессов по количеству для пользователя
man ulimit почитай.
Заодно почитай man initscript
Re: Лимит процессов по количеству для пользователя
Так ulimit выставляет ограничения для процессов запускаемых через bash, или глобально (через ядро) ?
Re: Лимит процессов по количеству для пользователя
Источник
системные настройки высоконагруженного сервера
Настройки Linux по-умолчанию не годятся для высоких нагрузок. Под высокими нагрузками я понимаю от 10000 запросов в секунду. В данной статье рассмотрим два «переключателя», покрутив которые мы добьемся от сервера устойчивости и отзывчивости при высоких нагрузках. Эти переключатели: limits.conf и sysctl.conf
limits.conf
Это конфигурационный файл для pam_limits.so модуля. Он определяет ulimit лимиты для пользователей и групп. В Linux есть системные вызовы: getrlimit() и setrlimit() для получения и установления лимитов на системные ресурсы. Конфигурация по-умолчанию лежит в /etc/security/limits.conf. Также присутствует возможность добавлять отдельные конфиги для приложений в /etc/security/limits.d. Для того, чтобы сервер держал большую нагрузку, нужно увеличить некоторые лимиты. Посмотрим, какие лимиты у нас стоят по-умолчанию. Запустим под рутом.
Обратим внимание на open files, max user processes и max locked memory. Это стандартные ограничения, которые нужно убрать, если хотим держаться под нагрузкой. Перед изменениями хочу предупредить, что если железо недостаточно мощное, то ваш сервер может подвергнуться атаке типа fork bomb, так что аккуратно раздавайте права на сервере.
Приведем /etc/security/limits.conf к такому виду.
В файле мы устанавливаем мягкий и жесткий лимиты на количество запущенных процессов, открытых файлов (читай портов) для всех пользователей и неограниченный лок памяти для рута.
Хочу поподробнее рассказать, почему для открытых файлов было выбрано ограничение в 1048576. Это волшебное число захардкожено в ядре, чтоб поставить больше, нужно пересобирать ядро. Более развернуто на эту тему отвечают на stackoverflow и вот здесь.
Изменения вступят в силу или после перезагрузки или после нового логина или создания сессии ssh. Проверить, включается ли модуль pam_limits можно в файлах /etc/pam.d Для Debian есть статья в wiki на эту тему: https://wiki.debian.org/Limits
sysctl.conf
В /etc/sysctl.conf настраиваются параметры ядра, модулей и других подсистем. По сути, можно вручную менять значения псевдо-фс /proc, но такие изменения не сохранятся после перезагрузки, поэтому будем сразу вносить изменения в этот конфиг файл.
Для пользователей systemd этот файл уже не играет роли. Если вы вдруг используете systemd, вам нужно править файлы в /etc/sysctl.d/. Подробнее читайте на http://www.freedesktop.org/software/systemd/man/sysctl.d.html
Вот пример моего sysctl.conf для высоконагруженной системы.
Подробно про все опции, можно прочитать в
Или, например, здесь. А тут написано как люди выдерживают миллион pps в секунду и приведены примеры используемых sysctl.conf
После изменения sysctl.conf применим наши правки.
После перезагрузки все изменения будут применяться автоматически.
Заключение
Все вышеописанное применялось мной на работе для высоконагруженного сервера, который перед выкаткой в прод тестировался замечательным Yandex танком и держал нагрузку порядка 20000 rps. Стоит учесть, что сам по себе Linux не обеспечит вам стойкости под нагрузкой, если ваш софт ломается при 100 rps. Тут уже вас может спасти балансировка нагрузки. Смотрите в сторону HAProxy, LVS, Keepalived. Удачного прохождения высоких нагрузок!
Источник