PM2 vs systemd: что выбрать для Node.js в 2026

Сравнение PM2 и systemd для продакшен-процессов Node.js: практические шаги, примеры команд и рекомендации по выбору. Время выполнения практических шагов: 20–40 минут.

Шаг 1: Установить Node.js и подготовить примеры приложения

Команда установки Node.js 20 и создание минимального приложения Express для тестов.

sudo apt update && sudo apt install -y curl ca-certificates
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs build-essential
mkdir -p ~/pm2-vs-systemd-demo && cd ~/pm2-vs-systemd-demo
cat > index.js <<'JS'
const http = require('http');
const port = process.env.PORT || 3000;
http.createServer((req, res) => {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('ok
');
}).listen(port, () => console.log('listening', port));
JS
npm init -y

Ожидаемый вывод: команда установки Node.js завершится без ошибок; запуск сервера выведет строку "listening 3000" в консоль.

$ node index.js
listening 3000

Типичная ошибка: «npm: command not found» или «node: command not found». Фикс: проверьте, что пакет nodejs установлен, и перезапустите сессию терминала. Если ошибка сохраняется, выполните which node и убедитесь, что путь есть в $PATH.

Шаг 2: Запустить приложение под PM2

Команды установки PM2 5.2 и запуска приложения в режиме single/cluster.

sudo npm install -g pm2@5.2.0
pm2 start index.js --name demo-app
pm2 status

Ожидаемый вывод: PM2 покажет процесс с именем demo-app, статус online, и потребление памяти/CPU.

$ pm2 status
┌─────┬──────────┬──────┬──────┬────────┬──────┬─────────────┐
│ id  │ name     │ mode │ pid  │ status │ cpu  │ memory      │
├─────┼──────────┼──────┼──────┼────────┼──────┼─────────────┤
│ 0   │ demo-app │ fork │ 1234 │ online │ 0%   │ 15.0 MB     │
└─────┴──────────┴──────┴──────┴────────┴──────┴─────────────┘

Типичная ошибка: «EACCES: permission denied» при глобальной установке PM2. Фикс: используйте sudo или настройте npm prefix в домашней директории (npm config set prefix '~/.npm-global'), затем добавьте его в $PATH.

Шаг 3: Интеграция PM2 с systemd (генерация unit-файла)

PM2 умеет генерировать systemd unit, чтобы сервис запускался при старте системы. Команды и ожидания.

pm2 save
pm2 startup systemd -u $USER --hp $HOME
# При успехе PM2 выведет команду, которую нужно выполнить с sudo. Например:
# sudo env PATH=$PATH:/usr/bin pm2 startup systemd -u ubuntu --hp /home/ubuntu

Ожидаемый вывод: PM2 выведет служебную инструкцию и создаст запись автозапуска; systemctl покажет юнит pm2-.service.

$ systemctl status pm2-ubuntu
● pm2-ubuntu.service - PM2 process manager
   Loaded: loaded (/etc/systemd/system/pm2-ubuntu.service; enabled)
   Active: active (running) since Mon 2026-03-01 10:00:00 UTC;

Типичная ошибка: «Failed to execute command: No such file or directory» при выполнении предложенной команды с sudo. Фикс: убедитесь, что в окружении при sudo есть PATH; выполните команду полностью с env, как предложено в выводе PM2.

Шаг 4: Создать systemd unit вручную для Node.js

Если нужна минимальная зависимость от внешних инструментов, systemd unit позволяет напрямую управлять процессом Node.js. Пример unit-файла и команды управления.

sudo tee /etc/systemd/system/node-demo.service > /dev/null <<'UNIT'
[Unit]
Description=Node.js Demo App
After=network.target

[Service]
Type=simple
User=ubuntu
Environment=PORT=3001
WorkingDirectory=/home/ubuntu/pm2-vs-systemd-demo
ExecStart=/usr/bin/node index.js
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
UNIT

sudo systemctl daemon-reload
sudo systemctl enable --now node-demo.service
sudo systemctl status node-demo.service

Ожидаемый вывод: статус active (running), лог «listening 3001» в journalctl -u node-demo.service -n 50.

$ sudo systemctl status node-demo.service
● node-demo.service - Node.js Demo App
   Loaded: loaded (/etc/systemd/system/node-demo.service; enabled)
   Active: active (running) since Mon 2026-03-01 10:05:00 UTC;

Типичная ошибка: «Permission denied» при запуске unit от имени пользователя. Фикс: проверьте права на index.js и рабочую директорию, убедитесь, что файл исполняется пользователем, указанным в unit (здесь ubuntu), или используйте User=root с осторожностью.

Шаг 5: Тестирование поведения при рестарте и обновлении кода

Проверяем автоматический рестарт и zero-downtime стратегии (PM2 cluster или graceful restart с systemd).

# Тест рестарта PM2
pm2 restart demo-app
pm2 show demo-app

# Тест рестарта systemd
sudo systemctl restart node-demo.service
sudo journalctl -u node-demo.service -n 50 --no-pager

Ожидаемый вывод: для PM2 статус изменится на online, для systemd — служба перезапустится без задержек; в логах появится запись о старте.

$ pm2 show demo-app
┌───────────────────┬─────────────────────────────────────┐
│ status            │ online                              │
└───────────────────┴─────────────────────────────────────┘

Типичная ошибка: при деплое обновления PM2 не перезапускает процесс, если используется pm2 pull без сохранения состояния. Фикс: для zero-downtime используйте pm2 reload (cluster mode) или последовательность pm2 stop/pm2 start и сохраняйте конфигурацию через pm2 save.

Шаг 6: Мониторинг, логирование и ресурсы

Инструменты и команды для мониторинга использования памяти/CPU, ротации логов и анализ отказов.

# PM2 встроенное логирование и ротация
pm2 logs demo-app --lines 50
pm2 install pm2-logrotate
pm2 set pm2-logrotate:compress true

# systemd: просмотр логов и настройка ротации
sudo journalctl -u node-demo.service -f
# Настройка ротации systemd-journald в /etc/systemd/journald.conf

Ожидаемый вывод: логи в режиме реального времени; при включенном pm2-logrotate файлы логов будут ротацироваться и сжиматься.

$ pm2 logs demo-app
0|demo-app  | listening 3000
0|demo-app  | GET / 200 -

Типичная ошибка: накопление логов и переполнение диска. Фикс: включите ротацию (pm2-logrotate) или настройте SystemMaxUse и SystemKeepFree в /etc/systemd/journald.conf.

Чем отличаются?

PM2 — это процессный менеджер уровня Node.js с возможностями кластеризации, управлением логами и встроенным мониторингом (релизы 2023–2024: PM2 5.x). systemd — системный менеджер процессов, встроенный в большинство современных дистрибутивов Linux (версии 2023–2025: systemd 252–259). Основные отличия по категориям:

• Подход: PM2 ориентирован на разработчиков Node.js: простые команды, кластерный режим, рестарты по умолчанию. systemd — системный сервис-менеджер с мощной моделью зависимости между юнитами.
• Автозапуск: PM2 генерирует unit для systemd или использует собственный механизм автозапуска. systemd нативно управляет стартапом без посредников.
• Логирование: PM2 пишет в лог-файлы и имеет плагины для ротации. systemd использует journalctl, централизованное хранение и политики ротации.
• Кластеризация: PM2 предлагает builtin cluster mode для Node.js (zero-downtime reload с pm2 reload). systemd не предоставляет приложение-ориентированной кластеризации — её нужно строить внешними инструментами (nginx, оператор Kubernetes или supervisor).
• Сложность и контроль: systemd даёт тонкие настройки лимитов, зависимостей и безопасности (cgroup, sandboxing). PM2 скрывает часть деталей, что удобно, но даёт меньше контроля над системными ресурсами.

Когда PM2?

PM2 подходит, если приоритеты следующие: быстрая настройка, отсутствие сложной интеграции с другими системными сервисами и требование встроенной кластеризации/мониторинга. Конкретные сценарии:

• Приложение Node.js, которое нужно быстро развернуть на VPS или в окружении без оркестратора (время настройки 5–15 минут).
• Нужен zero-downtime деплой с использованием pm2 reload и управление несколькими процессами через одну команду.
• Команда предпочитает JavaScript-центрированные инструменты: запуск, мониторинг и ротация логов через плагины PM2.

Ограничения: PM2 требует Node.js runtime и зависимости, для крупных инфраструктурных нужд (жесткое ограничение cgroups, интеграция с systemd unit dependency) предпочтителен systemd. Если нужен лёгкий менеджер процессов без дополнительного слоя, выбирайте systemd.

Когда systemd?

systemd оптимален для инфраструктурного контроля, безопасности и интеграции с другими сервисами на уровне ОС. Сценарии использования:

• Серверы с требованием строгой политики ресурсов (cgroup limits, NOFILE, секция LimitMEMLOCK и др.).
• Интеграция с CI/CD, когда деплой приводит systemd unit в состояние, которое удобно контролировать через systemctl и наблюдать через journalctl.
• Контроль зависимостей между сервисами: After=, Requires=, тайминги старта и graceful shutdown.

Ограничения: потребуется дополнительная логика для zero-downtime перезапуска (например, load balancer + rolling restarts) и отдельные скрипты для кластеризации. Для команд, которые хотят прозрачный системный контроль и безопасность — systemd предпочтительнее.

Частые вопросы

Когда стоит комбинировать PM2 и systemd?

Комбинация оправдана: PM2 управляет жизненным циклом Node.js приложений и предоставляет кластеринг/мониторинг, а systemd гарантирует автозапуск и контроль на уровне ОС. Распространённая практика — запуск PM2 как systemd-сервиса (генерация через pm2 startup) и использование systemd для управления жизненным циклом сервера и логики зависимостей. Это решает задачу удобства разработки и надёжности на уровне хоста.

Какой менеджер лучше для контейнеров (Docker) в 2026?

В контейнерах обычно не нужен отдельный процессный менеджер: orchestration (Kubernetes, Docker Compose) управляет restart policy. Если контейнер запускается напрямую на хосте, запускайте Node.js процесс как PID 1 или используйте tini; PM2 внутри контейнера усложняет PID tree и логику управления. Для sidecar-архитектуры и управления масштабированием в контейнерах предпочтительнее orchestration-инструменты, а не PM2/systemd внутри контейнера.

Как минимизировать простои при деплое?

Для zero-downtime деплоя используйте PM2 cluster mode с pm2 reload или настройте rolling updates через балансировщик (nginx, HAProxy) и systemd units, запускаемые поочерёдно. В больших инфраструктурах используйте blue/green или canary релизы через CI/CD (GitHub Actions) и автоматизированные health checks, чтобы переключение трафика происходило только на здоровые экземпляры.

Чем управлять логами: PM2 или systemd?

Если нужна единая точка логирования и централизованная ротация, systemd + journalctl (вкупе с rsyslog/ELK/Promtail) даёт преимущество. PM2 удобен для разработки и локального деплоя, но в продакшене лучше отправлять логи в централизованный стек (Loki, Elasticsearch) через stdout/stderr и собирать их сервисом, интегрированным с systemd или контейнерным лог-драйвером.

Сколько памяти потребляет PM2 поверх Node.js?

Оверхед PM2 5.x обычно составляет от 10 до 30 MB в состоянии простоя; при большом количестве процессов добавляется ~5–10 MB на процесс в зависимости от метрик. Если профиль памяти критичен, измерьте через pm2 monit или systemd cgroup metrics; для микросервисов с 512 MB памяти экономичнее использовать нативный systemd.