Ограничение CPU с cpulimit на Debian/Ubuntu

Введение

Этот туториал показывает, как ограничить использование CPU процесса с помощью утилиты cpulimit на Debian/Ubuntu. cpulimit ограничивает реальное потребление CPU в процентах (не суммарное CPU-время). Это полезно для пакетных задач и фоновых процессов, которые не должны «съедать» всё время процессора. Программа не меняет nice или приоритет планировщика — она управляет фактическим использованием CPU и может динамически подстраиваться под общую нагрузку системы.

Важно: я не гарантирую работоспособность в любой среде — тестируйте на вашей системе.

Предварительная заметка

Все команды в примерах выполняются от root. На Debian вы можете залогиниться как root напрямую, на Ubuntu — перейти в root так:

sudo su

Как считать проценты CPU: если у вас 1 физический/логический процессор, диапазон 0%–100%. Если 4 логических CPU, то суммарный показатель в top может доходить до 400%. Установка 200% на 4CPU означает, что процесс сможет использовать в сумме половину доступной мощности. В top или htop это значение совпадает с тем, что вы видите.

Рекомендация: cpulimit должен запускаться с тем же пользователем, что и контролируемый процесс. Лучше запускать cpulimit от root — это даёт более высокий приоритет и точное управление.

Установка cpulimit

Пакет доступен в репозиториях Debian/Ubuntu:

aptitude install cpulimit

Альтернативно используйте apt:

sudo apt update && sudo apt install cpulimit

Использование cpulimit

Ознакомьтесь со страницей man, чтобы понять синтаксис:

man cpulimit

Ниже — переведённая и сжатая версия man-страницы для удобства (формат сохранён):

NAME
cpulimit -- ограничивает использование CPU процессом

SYNOPSIS
cpulimit TARGET [OPTIONS...]

DESCRIPTION
TARGET должен быть ровно одним из вариантов:

-p, --pid=N
    pid процесса

-e, --exe=FILE
    имя исполняемого файла

-P, --path=PATH
    абсолютный путь к исполняемому файлу

OPTIONS

-l, --limit=N
    процент CPU разрешённый от 0 до 100 (обязательно)

-v, --verbose
    показывать статистику управления

-z, --lazy
    выйти, если нет подходящего процесса или если он завершился

-h, --help
    показать помощь и выйти

EXAMPLES
Если вы запустили процесс 'foo --bar' и видите в top или ps, что он загружает CPU, можно:

cpulimit -e foo -l 50
    ограничит по имени исполняемого файла (аргумент '--bar' не используется)

cpulimit -p 1234 -l 50
    ограничит процесс по PID

cpulimit -P /usr/bin/foo -l 50
    то же самое, что -e, но по полному пути

AUTHOR
Эта man-страница была написана для проекта Debian gregor herrmann.

Примеры команд в реальной системе.

Ограничить все процессы apache2 до 30% (по имени исполняемого файла):

cpulimit -e apache2 -l 30

Или по PID (узнайте PID через ps):

ps aux
ps aux | grep apache2
cpulimit -p 4510 -l 30

Или по абсолютному пути к бинарю:

cpulimit -P /usr/sbin/apache2 -l 30

Важно: cpulimit обычно работает в интерактивной сессии и остаётся в foreground пока вы его не остановите (Ctrl+C). При остановке cpulimit ограничение снимается.

Когда cpulimit подходит, а когда нет

Подходит:

Быстрые ad-hoc ограничения фоновых задач и скриптов.
Системы без активной поддержки systemd slice/cgroup, где нужно простое решение.
Сценарии, где не требуется долговременная политика управления ресурсами.

Не подходит / ограничения:

Процессы с высоким количеством потоков: cpulimit оперирует на уровне процесcа и может некорректно учитывать многопоточность.
Системные и kernel-процессы: cpulimit не управляет kernel threads.
Нужен длительный и предсказуемый QoS для сервисов — лучше cgroups/systemd.

Когда cpulimit «ломается»:

Если процесс быстро создаёт и убивает дочерние процессы, cpulimit может их не поймать.
В контейнерах с менеджером ресурсов (Docker, systemd) лучше использовать встроенные лимиты.

Альтернативные подходы

systemd: настроить Slice или Service с параметрами CPUQuota или CPUShares (рекомендуется для сервисов под systemd).
cgroups v1/v2: тонкое управление CPU, памятью и IO; подходит для контейнеров и SRE-практик.
nice/renice: меняет приоритет планировщика, но не ограничивает процент CPU.
cpuset/taskset: привязка процесса к ядрам (ограничивает доступ по CPU, но не по проценту).
Docker: опции –cpus, –cpu-quota.

Примеры systemd для сравнения (быстрая иллюстрация):

# в юните сервиса
CPUQuota=30%

Этот подход лучше для долгоживущих демон-сервисов, управляемых systemd.

Ментальная модель

“Процент” в cpulimit отражает долю одного логического CPU. На 4 логических CPU 100% = одно логическое ядро, 400% = полностью загруженная машина.
cpulimit задерживает выполнение процесса (посылает SIGSTOP/SIGCONT) в соответствии с требуемой квотой, поэтому поведение не такое как при изменении nice — это «торможение» по времени.

Пошаговый SOP: воспроизведение и контроль (образец для администратора)

Определите проблему: запустите top/htop, найдите процессы с высоким %CPU.
Найдите PID/имя/путь бинаря: ps aux | grep <имя>
Тестирование: запустите cpulimit в интерактивной сессии на 1–2 минуты и наблюдайте.
- По PID: cpulimit -p 1234 -l 30
- По имени: cpulimit -e processname -l 30
Наблюдайте метрики: top, vmstat, iostat, время отклика сервиса.
Если результат удовлетворяет — запланируйте запуск cpulimit через systemd unit или cron@reboot (учтите, что при падении cpulimit лимит снимается).
Для постоянного и надёжного контроля используйте cgroups/systemd.

Шпаргалка команд (cheat sheet)

Установка:

sudo apt install cpulimit

Ограничение по имени:

cpulimit -e apache2 -l 30

Ограничение по PID:

cpulimit -p 4510 -l 30

Ограничение по абсолютному пути:

cpulimit -P /usr/sbin/apache2 -l 30

Запуск в фоне (пример):

nohup cpulimit -p 4510 -l 30 &

Замечание: при использовании nohup cpulimit продолжит работать, но вы всё равно должны контролировать его устойчивость и перезапуск при падении процесса.

Критерии приёмки

После применения cpulimit процесс стабильно держит CPU ≲ заданного значения в течение 5 минут при обычной нагрузке.
Сопутствующие сервисы не деградируют критично (проверка ответа HTTP для веб-сервиса, задержки DB-запросов).
Логи и мониторинг не фиксируют новых ошибок, связанных с таймаутами.

Роли и чеклисты

Администратор:

Обнаружить проблемный процесс.
Сделать резервную копию конфигураций перед вмешательством.
Протестировать cpulimit в staging перед production.

Разработчик:

Проверить, можно ли оптимизировать код вместо ограничения CPU.
Добавить лимиты в CI/CD для долгих задач.

SRE:

Предложить долгосрочное решение (cgroups/systemd).
Автоматизировать перезапуск и обнаружение падений cpulimit.

Совместимость и миграция

cpulimit доступен в официальных репозиториях Debian/Ubuntu, но версии могут отличаться. На новых системах с cgroups v2 и агрессивным управлением ресурсами systemd, предпочтительнее systemd-run / CPUQuota.
Если система работает в контейнере, проверьте, поддерживает ли хостовые cgroups управление ресурсами; внутри контейнера cpulimit ограничит процесс в пределах доступного ему виртуального CPU.

Примеры тестов и сценариев

Тест нагрузки: запустите стресс-тест (например, stress-ng) и проверьте, что cpulimit удерживает %CPU.
Сценарий восстановления: остановите cpulimit и проверьте, как быстро процесс вернётся к предыдущему уровню CPU.
Граничный тест: установите 0% и 100% и проверьте поведение (0% эквивалентно сильному ограничению, но будьте осторожны — это может заблокировать процесс).

Ссылки

cpulimit: http://cpulimit.sourceforge.net/

Итог

cpulimit — удобный инструмент для быстрых ограничений использования CPU на Debian/Ubuntu. Он хорош для одноразовых корректировок и экспериментов, но для долгосрочного, предсказуемого управления ресурсами стоит рассмотреть systemd и cgroups. Всегда тестируйте изменения в staging и контролируйте влияние на сервисы.

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