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

Динамическое и статическое управление ресурсами программ в Linux

Да, в Linux существует богатый набор механизмов для управления ресурсами, выделяемыми запущенным программам (процессам). Это можно сделать как статически (задав ограничения перед запуском), так и динамически (меняя параметры уже работающего процесса). Основные ресурсы, которыми можно управлять: процессорное время (CPU), оперативная память (RAM), дисковый ввод-вывод (I/O) и сетевая полоса пропускания.

Ключевые технологии и интерфейсы управления

1. cgroups (Control Groups)

Это ядро Linux для ограничения, учета и изоляции ресурсов. Основной современный инструмент. Работает через виртуальную файловую систему cgroup2 (или cgroup v1).

• CPU: Ограничение доли процессорного времени через cpu.cfs_quota_us и cpu.cfs_period_us.
• Память: Установка лимита memory.max и memory.swap.max.
• Дисковый I/O: Ограничение через io.max для блочных устройств.

Пример создания cgroup и запуска процесса с ограничением CPU в 50% одного ядра и памяти в 512 МБ:

# Создаем cgroup (на примере systemd, как наиболее распространенного)
sudo systemd-run --scope -p CPUQuota=50% -p MemoryMax=512M --user /путь/к/программе

# Или ручное управление через cgroup v2
sudo mkdir /sys/fs/cgroup/myapp
echo 500000 > /sys/fs/cgroup/myapp/cpu.max     # 0.5 ядра (500ms из 1000ms периода)
echo 536870912 > /sys/fs/cgroup/myapp/memory.max # 512 МБ в байтах
echo $$ > /sys/fs/cgroup/myapp/cgroup.procs     # Текущий shell и его дочерние процессы
./моя_программа

2. Systemd

Использует cgroups «под капотом» и предоставляет удобный интерфейс через юниты служб (service) и областей (scope).

• Для служб: Параметры в секции [Service] файла .service:

  [Service]
  CPUQuota=150%
  MemoryMax=1G
  IOWeight=100
  

• Для интерактивных программ: Использование systemd-run, как в примере выше.

3. ulimit (встроенная команда shell)

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

# Установить ограничение на виртуальную память (в кибибайтах) и запустить программу
ulimit -v 1048576 # 1 ГБ
./моя_программа

Однако ulimit менее гибок, чем cgroups (например, не может ограничить общее использование RAM, только отдельные сегменты).

4. nice и renice

Управление приоритетом планировщика CPU (nice value). Чем выше значение (от -20 до 19), тем «добрее» процесс к другим (ниже приоритет).

nice -n 10 ./моя_программа  # Запуск с низким приоритетом
renice -n 15 -p 1234        # Изменить приоритет уже работающего процесса PID 1234

5. ionice

Управление классом и приоритетом дискового ввода-вывода. Доступные классы: Idle, Best-effort (по умолчанию), Realtime.

ionice -c 2 -n 5 ./моя_программа  # Класс Best-effort с приоритетом 5
ionice -c 3 -p 1234                # Перевести процесс PID 1234 в класс Idle

6. taskset и numactl

Привязка процессов к конкретным ядрам CPU (аффинити процессора) и узлам NUMA. Это не жесткое ограничение, а указание планировщику.

taskset -c 0-3 ./моя_программа  # Запуск только на ядрах 0,1,2,3
numactl --cpunodebind=0 --membind=0 ./программа  # Привязка к узлу NUMA 0

Практическое применение: контейнеризация и оркестрация

Все современные технологии контейнеризации (Docker, containerd, Podman) активно используют cgroups для изоляции ресурсов. Например, в Docker:

# В Dockerfile можно задать рекомендации
# Но реальные ограничения задаются при запуске

docker run --cpus="1.5" --memory="512m" --memory-swap="1g" --blkio-weight=500 my-image

Оркестраторы, такие как Kubernetes, определяют запросы (requests) и лимиты (limits) ресурсов для подов:

# Фрагмент манифеста пода в Kubernetes
resources:
  requests:
    memory: "256Mi"
    cpu: "250m"  # 0.25 ядра
  limits:
    memory: "512Mi"
    cpu: "500m"  # 0.5 ядра

Kubernetes передает эти параметрии через CRI (Container Runtime Interface) в runtime (например, containerd), который, в свою очередь, настраивает cgroups в ядре Linux.

Выбор подхода и рекомендации

• Для разовых задач: systemd-run или прямая работа с cgroup v2 через sysfs.
• Для системных служб: Конфигурация через systemd unit files.
• Для изолированных окружений (продакшен): Контейнеризация (Docker/Kubernetes).
• Для быстрых ограничений в сессии: ulimit, nice, ionice.

Важно помнить, что жесткие ограничения (limits) могут привести к завершению процесса (OOM Killer при превышении памяти, паузы/throttling для CPU). Поэтому мониторинг (через systemd-cgtop, cgstats, /sys/fs/cgroup/) и настройка лимитов с запасом критически важны.

Таким образом, Linux предоставляет DevOps-инженеру исчерпывающий, многоуровневый инструментарий для точного контроля над ресурсами процессов — от простых команд shell до сложных систем контейнеризации, работающих поверх абстракций ядра.