Планирование ресурсов

Это руководство помогает рассчитать размер установки Mockarty до запуска: сколько
процессора и памяти нужно каждому компоненту, сколько соединений с PostgreSQL
заложить и какие настройки менять по мере роста. Числа ниже — реальные значения
продукта по умолчанию, а не оценки.

Как компоненты связаны между собой, описано в разделе Архитектура масштабирования.

Начальные размеры

Десктопной или ознакомительной установке нужен только узел администрирования:
он может хранить данные в локальном файле SQLite, а кэш — в памяти.

Значения Helm-чарта по умолчанию

Helm-чарт задаёт запросы и лимиты, с которыми каждый под запускается на небольшом
кластере. Считайте их нижней границей: для продакшена задайте узлу
администрирования процессор и память не ниже рекомендованных выше.

Измените их в своём файле values, например:

admin:
  resources:
    requests: { cpu: "1", memory: 2Gi }
    limits: { cpu: "4", memory: 4Gi }

Соединения с PostgreSQL

Нехватка соединений с базой — самая частая проблема ёмкости в установке из
нескольких узлов: запросы начинают падать, хотя процессора и памяти достаточно.
Рассчитайте число соединений до масштабирования.

Каждый узел администрирования держит два пула соединений и несколько отдельных
соединений для обновлений в реальном времени:

«CPU» — это лимит процессора контейнера узла администрирования (или число
процессоров машины, если лимита нет). Поэтому один узел использует не больше:

на узел администрирования = DB_MAX_OPEN_CONNS + BOOTSTRAP_DB_MAX_OPEN_CONNS + 10

Посчитайте все поды, которые могут существовать одновременно, — максимум
автомасштабирования плюс дополнительный под, который запускает плавное
обновление, — и держите итог не выше 80 % от max_connections PostgreSQL.
Остальное нужно для резервного копирования, миграций и ваших собственных сессий:

итого = (поды администрирования + запас) × на узел + (поды резолверов + запас) × 3

Как складываются профили самого чарта:

Именно поэтому чарт поднимает max_connections у встроенного PostgreSQL:
собственного значения PostgreSQL по умолчанию, 100, не хватает даже одному узлу
администрирования во время плавного обновления. С внешним PostgreSQL примените
формулу к своей схеме и либо поднимите max_connections, либо уменьшите пулы:

admin:
  env:
    DB_MAX_OPEN_CONNS: "15"
    BOOTSTRAP_DB_MAX_OPEN_CONNS: "16"
postgresql:
  primary:
    extendedConfiguration: |
      max_connections = 300

Каждое соединение стоит PostgreSQL памяти, поэтому поднимайте память PostgreSQL
вместе с max_connections. При большом числе резолверов пул соединений перед
PostgreSQL держит их количество низким.

SQLite (десктоп и единый бинарник)

Узел, хранящий данные в SQLite, открывает основной пул по 2 соединения на CPU
(от 4 до 32, переопределяется SQLITE_MAX_OPEN_CONNS) и служебный пул по 1 на
CPU (от 4 до 8). Чтение идёт параллельно, запись — по очереди. SQLite подходит
одному человеку или небольшой команде на одной машине — переходите на PostgreSQL
до того, как запись начнут вести несколько человек одновременно.

Redis

Каждый узел администрирования открывает до 10 соединений с Redis на CPU, но не
меньше 20 (переопределяется CACHE_REDIS_POOL_SIZE), и держит не меньше 4 из них
готовыми (CACHE_REDIS_MIN_IDLE_CONNS). Если Redis ограничивает число клиентов,
держите поды администрирования × размер пула ниже его maxclients.

Кэш в памяти

Без Redis каждый узел администрирования кэширует в собственной памяти, по
умолчанию до 200 МБ (REPO_INMEMORY_MAX_SIZE_MB). Учитывайте его в лимите
памяти узла.

Диск

Диск базы растёт вместе с хранимой историей — журналами запросов, результатами
тестовых прогонов и журналом аудита, — а не с числом моков или пользователей.
Настройте политики очистки в панели администрирования под нужный срок хранения,
затем планируйте диск как суточный объём × дни хранения плюс около 30 % запаса.
Большие файлы отчётов и вложения попадают в файловое или объектное хранилище,
его размер рассчитывайте отдельно. В разделе Архитектура масштабирования
есть примеры для небольших, средних и крупных команд.

Когда масштабироваться