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, с ограниченным доступом к папкам и файлам, включая не только редактирование, но и просмотр, а также возможность использовать только разрешенные утилиты. Предусматривается только локальный доступ, сетевого доступа нет.
Что бы не изобретать велосипед, первым делом начал копать интернет, в результате чего были найдены следующие варианты:
- ограничения доступа через сетевые службы ssh, sftp (не подошло)
- разграничение прав доступа самой операционной системой linux (не подошло, хотелось бы универсальное решение)
- использование chroot (не подошло)
- использование сторонних утилит, например SELinux (не подошло, усложняет систему).
В результате поиска, был найден встроенный механизм ограничения возможностей пользователя внутри оболочки bash, он называется Restricted Shell или rbash.
В нем реализованы следующие ограничения:
- нет возможности смены каталога командой cd
- нельзя сбрасывать или изменять значения переменных SHELL, PATH, ENV, BASH_ENV
- запрещено указывать команды содержащие / (косую черту)
- запрещено импортировать функции из основной оболочки
- запрещено перенаправлять вывод с использованием операторов >, , >&, &>, >>
- запрещено использовать команду exec для подмены команды и пр.
Есть минус, это безопасность, поэтому необходимо в обязательном порядке добавить alias на команды в файл поведения оболочки .bashrc (информация будет далее).
Конечно rbash из коробки, всех задач не решает, поэтому на примере рассмотрим создание пользователя и настройка его окружения для полного решения нашей задачи.
Далее все операции выполняются от суперпользователя (root).
1. Создаем ограниченную оболочку
2. Создаем пользователя
3. Изменяем права директории
4. Переходим в директорию и очищаем ее
5. Настраиваем оболочку и права
Файл .bashrc определяет поведение командной оболочки, в данный файл можно добавить alias для команд или дополнительные опции.
Для обеспечения безопасности выполните следующие команды:
Данный список можно продолжать…
6. Проверяем работу
7. Добавляем допустимые команды
Важно, пути в команде ln необходимо указывать полностью.
8. Для ограничения опций команды можно использовать обертки
9. Для работы с файлами и папками можно также создать обертку
с черным списком (разрешить все, кроме):
— создаем файл
blacklist — переменная содержащая черный список директорий или файлов (через пробел)
— добавляем команду для пользователя zuser
Данный скрипт разрешает выполнять команду ls с любыми ключами для каталогов и файлов не совпадающих с черным списком
с белым списком (запретить все, кроме):
— создаем файл
whitelist — переменная содержащая белый список директорий или файлов (через пробел)
— добавляем команду для пользователя zuser
Данный скрипт разрешает выполнять команду cat с указанными файлами в белом списке
Готово, в итоге получили следующий результат:
- мы создали пользователя zuser с оболочкой rbash
- отключили возможность использования автодополнения в консоли
- zuser может запускать утилиты только из директории /home/zuser/bin
- добавили пользователю zuser команду ping
- добавили пользователю zuser собственную команду user-info
- пользователю zuser ограничили через обертку выполнение команд ls и cat
Данный способ к сожалению не гарантирует 100% безопасность, и при определенных знаниях и квалификации пользователь может покинуть данную оболочку. Спасибо Jouretz arheops YaDr они в комментариях привели примеры обхода ограничений оболочки.
Источник
Борьба за ресурсы, часть 1: Основы Cgroups
Компьютеры – это «железо». И сегодня мы вернулись в исходную точку, в том смысле, что сейчас редко найдешь физический хост, на котором выполняется одна единственная задача. Даже если на сервере крутится только одно приложение, оно, скорее всего, состоит из нескольких процессов, контейнеров или даже виртуальных машин (ВМ), и все они работают на одном сервере. Red Hat Enterprise Linux 7 неплохо справляется с распределением системных ресурсов в таких ситуациях, но по умолчанию ведет себя как добрая бабушка, угощающая внуков домашним пирогом и приговаривающая: «Всем поровну, всем поровну».
В теории принцип «всем поровну», конечно, прекрасен, но на практике некоторые процессы, контейнеры или ВМ оказываются важнее других, и, следовательно, должны получать больше.
В Linux уже давно есть средства управления использованием ресурсов (nice, ulimit и прочее), однако с появлением Red Hat Enterprise Linux 7 и systemd у нас наконец-то появился мощный набор таких инструментов, встроенный в саму ОС. Дело в том, что ключевой компонент systemd – это уже готовый, настроенный набор cgroups, который в полной мере задействуется на уровне ОС.
Хорошо, а что это вообще за cgroups, и причем здесь управление ресурсами или производительностью?
Контроль на уровне ядра
Начиная с вышедшей в январе 2008 года версии 2.6.24, в ядре Linux появилось то, что изначально было придумано и создано в Google под именем «process containers», а в Linux стало называться «control groups», сокращенно cgroups. Вкратце, cgroups – это механизм ядра, позволяющий ограничивать использование, вести учет и изолировать потребление системных ресурсов (ЦП, память, дисковый ввод/вывод, сеть и т. п.) на уровне коллекций процессов. Cgroups также могут замораживать процессы для проверки и перезапуска. Контроллеры cgroups впервые появились в 6-й версии Red Hat Enterprise Linux, но там их надо было настраивать вручную. А вот с приходом Red Hat Enterprise Linux 7 и systemd преднастроенный набор cgroups идет уже в комплекте с ОС.
Все это работает на уровне ядра ОС и поэтому гарантирует строгий контроль над каждым процессом. Так что теперь какому-нибудь зловреду крайне сложно нагрузить систему так, чтобы она перестала реагировать и зависла. Хотя, конечно, багованный код с прямым доступом к «железу» (например, драйверы), все еще на такое способен. При этом, Red Hat Enterprise Linux 7 предоставляет интерфейс для взаимодействия с cgroups, и вся работа с ними в основном ведется через команду systemd.
Свой кусок пирога
На диаграмме ниже, напоминающей нарезанный пирог, представлены три cgroups, которые по умолчанию есть на сервере Red Hat Enterprise Linux 7 – System, User и Machine. Каждая из этих групп называется «слайс» (slice – сектор). Как видно на рисунке, каждый слайс может иметь дочерние секторы-слайсы. И, как и в случае с тортом, в сумме все слайсы дают 100% соответствующего ресурса.
Теперь рассмотрим несколько концепций cgroups на примере процессорных ресурсов.
На рисунке выше видно, что процессорное время поровну делится между тремя слайсами верхнего уровня (System, User и Machine). Но так происходит только под нагрузкой. Если же какой-то процесс из слайса User попросит 100% процессорных ресурсов, и никому больше эти ресурсы в данный момент не нужны, то он получит все 100% процессорного времени.
Каждый из трех слайсов верхнего уровня предназначен для своего типа рабочих нагрузок, которым нарезаются дочерние сектора в рамках родительского слайса:
- System – демоны и сервисы.
- User – пользовательские сеансы. Каждый пользователь получает свой дочерний слайс, причем все сеансы с одинаковым UID «живут» в одном и том же слайсе, чтобы особо ушлые умники не могли получить ресурсов больше положенного.
- Machine – виртуальные машины, типа KVM-гостей.
Кроме того, для управления использованием ресурсов применяется концепция так называемых «шар» (share – доля). Шара – это относительный числовой параметр; его значение имеет смысл только в сравнении со значениями других шар, входящих в ту же cgroup. По умолчанию все слайсы имеют шару, равную 1024. В слайсе System на рисунке выше для httpd, sshd, crond и gdm заданы CPU-шары, равные 1024. Значения шар для слайсов System, User и Machine тоже равны 1024. Немного запутанно? На самом деле это можно представить в виде дерева:
- System — 1024
- httpd — 1024
- sshd — 1024
- crond — 1024
- gdm — 1024
- User — 1024
- bash (mrichter) — 1024
- bash (dorf) — 1024
- Machine — 1024
- testvm — 1024
В этом списке у нас есть несколько запущенных демонов, пара пользователей и одна виртуальная машина. Теперь представим, что все они одновременно запрашивают всё процессорное время, какое только можно получить.
- Слайс System получает 33,333% процессорного времени и поровну делит его между четырьмя демонами, что дает каждому из них по 8,25% ресурсов ЦП.
- Слайс User получает 33,333% процессорного времени и делит его между двумя пользователями, каждый из которых имеет по 16,5% ресурсов ЦП. Если пользователь mrichter выйдет из системы или остановит все свои запущенные процессы, то пользователю dorf станет доступно 33% ресурсов ЦП.
- Слайс Machine получает 33,333% процессорного времени. Если выключить ВМ или перевести ее в холостой режим, то слайсы System и User будут получать примерно по 50 % ресурсов ЦП, которые затем поделятся между их дочерними слайсами.
Кроме того, для любого демона, пользователя или виртуальной машины можно вводить не только относительные, но и абсолютные ограничения на потребление процессорного времени, причем не только одного, но и нескольких процессоров. Например, у слайса пользователя mrichter есть свойство CPUQuota. Если выставить его на 20 %, то mrichter ни при каких обстоятельствах не получит больше 20 % ресурсов одного ЦП. На многоядерных серверах CPUQuota может быть больше 100 %, чтобы слайс мог пользоваться ресурсами более чем одного процессора. Например, при CPUQuota = 200 % слайс может полностью задействовать два процессорных ядра. При этом важно понимать, что CPUQuota не резервирует, иначе говоря, не гарантирует заданный процент процессорного времени при любой загруженности системы – это лишь максимум, который может быть выделен слайсу с учетом всех прочих слайсов и настроек.
Выкручиваем на полную!
Как можно поменять настройки слайсов?
Для этого у каждого слайса есть настраиваемые свойства. И поскольку это Linux, мы можем вручную прописывать настройки в файлах конфигураций или же задавать из командной строки.
Во втором случае используется команда systemctl set-property. Вот что будет на экране, если набрать эту команду, добавить в конце имя слайса (в нашем случае User) и затем нажать клавишу Tab для отображения опций:
Не все свойства на этом скриншоте являются настройками cgroup. Нас в основном интересуют те, что начинаются на Block, CPU и Memory.
Если вы предпочитаете не командную строку, а config-файлы (например, для автоматизированного развертывания на нескольких хостах), то тогда придется заняться файлами в папке /etc/systemd/system. Эти файлы автоматически создаются при установке свойств с помощью команды systemctl, но их также можно создавать в текстовом редакторе, штамповать через Puppet или даже генерировать скриптами на лету.
Итак, с базовыми понятиями cgroups все должно быть ясно. В следующий раз пройдем по некоторым сценариям и посмотрим, как изменения тех или иных свойств влияют на производительность.
А буквально завтра приглашаем всех на Red Hat Forum Russia 2018 – будет возможность задать вопросы напрямую инженерам Red Hat.
Другие посты по cgroups из нашей серии «Борьба за ресурсы» доступны по ссылкам:
Источник
