План оптимизации нагрузки, приоритета ресурсов и отказоустойчивости

Дата: 2026-02-07
Приоритет: Комфортная работа администратора (ничего не должно «виснуть»)
Связано: disk-space-protection.md

1. Цели

2. Текущее состояние (кратко)

• Память: 14 ГБ RAM, ~9.3 ГБ занято, свободно ~188 МБ, swap ~945 МБ — высокая нагрузка на память, активен kswapd.
• CPU: Load average 17–29 при 12 ядрах; основной потребитель — ripgrep от Cursor (индексация), затем Cursor, Firefox, BigBlueButton, LXD/snapd.
• Диск: Защита от переполнения уже есть (disk-space-monitor, пороги, аварийная очистка). Корень 46%, /storage 78%.
• OOM: systemd-oomd включён, лимиты по умолчанию (MemoryPressure 60%, 20s). Глобальные лимиты сервисов не заданы (MemoryMax=infinity у Docker, GDM, LXD).
• Резервные/фоновые задачи: Бэкапы и docs-sync уже с низким приоритетом (Nice=19, IO=idle, CPUQuota 30–50%, MemoryMax 2–8 ГБ).

3. Приоритет использования ресурсов

3.1 Иерархия приоритетов (кто важнее)

1. Уровень 1 — Критично для работы ОС и входа
2. Ядро, systemd, GDM, SSH, диск (достаточно места).

3. Должны всегда получать ресурсы и не убиваться OOM первыми.

4. Уровень 2 — Работа администратора (ваш комфорт)

5. Сессия пользователя cdto: Cursor, браузер, gnome-shell, терминал, Cockpit.

6. Высокий приоритет по CPU и I/O, защита от OOM (не убивать первыми).

7. Уровень 3 — Критичные сервисы платформы

8. BigBlueButton (bbb-web, bbb-apps-akka, bbb-fsesl-akka), PostgreSQL, Nginx, coturn, Etherpad, Puma, Hasura.

9. Ограничить лимитами, но не «душить» при нормальной нагрузке.

10. Уровень 4 — Инфраструктура второго плана

11. Docker, LXD, Grafana, 1C (rmngr/ragent), snapd.

12. Ограничить CPU/RAM, низкий I/O приоритет при конкуренции.

13. Уровень 5 — Фоновые задачи

14. Бэкапы (backup-*), docs-sync, logrotate, apt, fwupd и т.п.
15. Уже низкий приоритет; при необходимости дополнительно ограничить по времени (запуск в ночные часы).

4. План по оптимизации нагрузки

4.1 Cursor IDE (снижение нагрузки на CPU и диск)

• Проблема: ripgrep индексирует огромное дерево файлов → сотни процентов CPU.
• Действия:
• Сузить область поиска в .cursorignore в корне проектов (и в домашнем каталоге, если Cursor открывает его):
  • Добавить: /D, /storage, **/node_modules, **/.git, **/backups, **/.lxd, **/var/snap/lxd, большие каталоги с данными.
• Не открывать в Cursor весь домашний каталог или корень; открывать только нужные проекты (например, ~/DENKART, ~/project1).
• Эффект: Снижение пиковой нагрузки по CPU и I/O, меньше конкуренции с сессией администратора.

4.2 BigBlueButton и связанные сервисы

• Сервисы под пользователем dnsmasq: Java (bbb-web), Scala (bbb-apps-akka, bbb-fsesl-akka), Node (Etherpad), Puma, Hasura.
• Действия:
• Задать для каждого ограничения RAM и CPU через systemd (см. раздел 6), чтобы при нехватке памяти первыми ограничивались они, а не сессия администратора.
• Если BBB не используется постоянно — рассмотреть отложенный запуск (timer) или ручной старт при необходимости.

4.3 LXD и snapd

• LXD и snapd дают стабильные несколько процентов CPU.
• Действия:
• Задать MemoryMax и CPUQuota для snap.lxd.daemon.service и при необходимости для snapd.service, чтобы они не раздувались и не конкурировали с сессией администратора.
• Если контейнеры LXD не нужны — можно отключить сервис LXD.

4.4 Память и swap

• swappiness=10 — уже нормально (меньше свопинга).
• Действия:
• Включить systemd-oomd с явными порогами и, при возможности, с ManagedOOM для пользовательской сессии (см. раздел 6).
• Задать MemoryHigh/ MemoryMax для тяжёлых сервисов (Docker, LXD, BBB, Grafana), чтобы OOM сначала «давил» их, а не рабочий стол.

4.5 Дисковое пространство

• Мониторинг и аварийная очистка уже реализованы (disk-space-monitor, пороги, резерв для загрузки).
• Действия:
• Периодически проверять /storage (сейчас 78%) и чистить старые образы/volumes Docker, логи, бэкапы по политике из disk-space-protection.md.
• Не ослаблять пороги и не отключать timer disk-space-monitor.

5. Проверка механизмов отказоустойчивости

5.1 Заполнение диска

Рекомендация: Раз в неделю выполнять sudo /usr/local/bin/disk-space-monitor.sh и смотреть логи; при приближении к 80% на /storage — планово чистить данные.

5.2 Нехватка памяти (OOM)

Проверка:
systemctl status systemd-oomd
systemd-analyze cat-config systemd/oomd.conf

5.3 Сбой сервисов (перезапуск, лимиты)

5.4 Резервное копирование

• Таймеры backup-bbb, backup-daily, backup-full-server, backup-postgres, backup-lxd-snapshots уже с низким приоритетом и лимитами.
• Рекомендация: Убедиться, что бэкапы не пересекаются по времени с пиковой работой администратора; при необходимости сдвинуть на глубокую ночь.

6. Конкретные шаги по внедрению

6.1 Приоритет сессии администратора (комфорт)

• Nice / I/O: Сессия пользователя по умолчанию уже с нормальным приоритетом. Дополнительно можно не понижать приоритет фоновых процессов Cursor (ripgrep), а только сузить им объём работы через .cursorignore.
• OOM — не убивать сессию первой:
  Настроить systemd-oomd так, чтобы в первую очередь учитывались сервисы с высоким потреблением памяти, а не user slice. Для этого:
• Задать MemoryMax/ MemoryHigh для тяжёлых системных сервисов (Docker, LXD, BBB, Grafana).
• В user.slice для cdto при необходимости задать ManagedOOMPressure=avoid (если поддерживается в вашей версии systemd), либо полагаться на то, что сервисы с лимитами будут убиваться/ограничиваться раньше.

6.2 Ограничения для сервисов (RAM и CPU)

Создать override для сервисов с высоким потреблением, чтобы они не «забирали всё» и первыми попадали под OOM/ограничения.

Примеры (значения подставить под ваши объёмы RAM и желаемый запас для рабочей машины):

• Docker (подстроено под 14 GB RAM: мониторинг не конкурирует с сессией)
  /etc/systemd/system/docker.service.d/resource-limits.conf:
  ini [Service] MemoryHigh=3G MemoryMax=4G CPUQuota=60%
• LXD (подстроено под 14 GB RAM)
  /etc/systemd/system/snap.lxd.daemon.service.d/resource-limits.conf:
  ini [Service] MemoryHigh=1G MemoryMax=2G CPUQuota=40%
• Grafana (если в systemd)
  Ограничить, например: MemoryMax=1G, CPUQuota=30%.

Для BBB (если они запускаются как systemd-сервисы под пользователем dnsmasq или как user units) — создать соответствующие override с MemoryMax/MemoryHigh и CPUQuota, чтобы суммарно они не превышали выделенный бюджет (например, 4–6 ГБ на все BBB-процессы).

Установка из репозитория DENKART: можно применить готовые шаблоны и OOM-настройки одной командой:

cd /home/cdto/DENKART/scripts
sudo ./install-resource-limits.sh

Скрипт копирует override для Docker и LXD и drop-in для systemd-oomd; в конце выведет команды перезапуска сервисов. После установки перезапустите при необходимости:

sudo systemctl restart docker
sudo systemctl restart snap.lxd.daemon.service
sudo systemctl restart systemd-oomd

6.3 OOMD — явные пороги (опционально)

Создать /etc/systemd/oomd.conf.d/10-reserve-admin.conf:

[OOM]
SwapUsedLimit=90%
DefaultMemoryPressureLimit=50%
DefaultMemoryPressureDurationSec=15s

Перезапуск: sudo systemctl restart systemd-oomd.

6.4 .cursorignore для снижения нагрузки

В домашнем каталоге или в корне открываемых в Cursor проектов создать/дополнить .cursorignore:

/D
/storage
**/node_modules
**/.git
**/backups
**/.lxd
**/var/snap/lxd
**/*.code-search

(Список можно сузить под реальные пути, которые не нужны для поиска в Cursor.)

6.5 Проверка после внедрения

• Наблюдать за нагрузкой: top, htop, vmstat 2.
• Проверить, что сессия (Cursor, браузер) остаётся отзывчивой при работе бэкапов и при высокой загрузке.
• Убедиться, что после установки MemoryMax сервисы не падают при штатной нагрузке (при необходимости поднять лимиты).
• Раз в неделю: df -h, free -h, просмотр логов disk-space-monitor и при необходимости — очистка диска.

7. Чек-лист внедрения

• [ ] Сузить область индексации Cursor (.cursorignore, не открывать лишние каталоги; пример в п. 6.4).
• [ ] Установить лимиты ресурсов: sudo /home/cdto/DENKART/scripts/install-resource-limits.sh, затем перезапустить docker, snap.lxd.daemon, systemd-oomd при необходимости.
• [ ] Задать MemoryHigh/MemoryMax и CPUQuota для Docker.
• [ ] Задать MemoryHigh/MemoryMax и CPUQuota для LXD (snap.lxd.daemon).
• [ ] При наличии unit-файлов BBB — задать лимиты для bbb-web, bbb-apps-akka, bbb-fsesl-akka и при необходимости для Etherpad/Puma/Hasura.
• [ ] Задать лимиты для Grafana (если управляется через systemd).
• [ ] (Опционально) Настроить oomd.conf.d: SwapUsedLimit, DefaultMemoryPressureLimit, DefaultMemoryPressureDurationSec.
• [ ] Проверить работу disk-space-monitor.timer и пороги по документации disk-space-protection.
• [ ] Проверить, что бэкапы не создают пиков нагрузки в рабочее время; при необходимости сдвинуть таймеры.
• [ ] Один раз проверить резерв на корне: tune2fs -l /dev/sdb2 | grep Reserved.

8. Итог

• Комфорт администратора: обеспечивается за счёт ограничения фоновых и сервисных процессов (CPU/RAM), сужения индексации Cursor и настройки OOM так, чтобы в первую очередь ограничивались сервисы с заданными лимитами.
• Диск: механизмы уже есть; важно не ослаблять пороги и следить за /storage.
• Отказоустойчивость: OOM (oomd), мониторинг диска и лимиты сервисов — ключевые механизмы; их нужно проверить по чек-листу и при необходимости донастроить по этому плану.

После выполнения пунктов раздела 6 и чек-листа раздела 7 система будет лучше предсказуема по нагрузке и отказоустойчивости при приоритете комфортной работы администратора.