Основные настройки

Масштабирование

В случае, когда нагрузка возрастает, для стабилизации работы платформы предусмотрено масштабирование следующих сервисов в ручном режиме:

• image-api-face-detector-liveness-estimator-dep
• image-api-quality-assessment-estimator
• image-api-age-estimator
• image-api-gender-estimator
• image-api-mask-estimator
• image-api-emotion-estimator
• image-api-face-detector-template-extractor-dep

Для масштабирования сервиса выполните команду:

kubectl scale deployment <SERVICE_NAME> --replicas <COUNT>

где <SERVICE_NAME> - наименование сервиса (например, gateway-dep), а <COUNT> - количество экземпляров сервиса.

Для поддержания нагрузки в A запросов/сек., направленной на обработку изображений, на сервере с физическим количеством ядер CPU равным B следует установить значение реплик каждого из указанных сервисов по формуле min(A, B).

Для сохранения параметров масштабирования откройте файлы ./cfg/platform.values.yaml и ./cfg/image-api.values.yaml, найдите поле replicas в блоке сервиса и укажите новые значения реплик.

При следующих установках платформы и image-api сервисы будут автоматически масштабироваться до указанных значений.

подсказка

При увеличении запросов поиска по изображению увеличьте число реплик сервиса image-api-face-detector-template-extractor-dep. Также можно увеличить количество потоков, которые используются для вычисления биометрического шаблона.

При увеличении запросов на детекцию, создание профилей и создание сэмплов увеличьте число реплик сервисов:

• image-api-face-detector-liveness-estimator-dep
• image-api-age-estimator
• image-api-gender-estimator
• image-api-mask-estimator
• image-api-emotion-estimator
• image-api-quality-assessment-estimator

Изменение TTL сэмплов и активностей

предупреждение

Значения для каждого из параметров указаны по умолчанию. Изменять значения параметров рекомендуется только в случае явной необходимости.

предупреждение

Параметр activity_ttl убран по умолчанию, т.к. добавлен функционал очистки по количеству хранящихся данных. При этом можно включить функционал, описанный здесь. Для этого в файле ./cfg/platform.values.yaml добавьте поле backend.activity_ttl: "2592000".

Файл ./cfg/platform.values.yaml:

• backend.activity_ttl: время хранения активностей в базе данных. Значение задается в секундах. Например, 2592000 секунд (30 дней).
• backend.sample_ttl: время хранения сэмплов в базе данных. Значение задается в секундах. Например, 2592000 секунд (30 дней).

Изменение количества хранящихся активностей и событий

Файл ./cfg/platform.values.yaml:

• backend.retention_activities_count: количество хранящихся активностей на один воркспейс.
• backend.activity_handler_period: частота проверки количества активностей в базе. Значение задается в секундах. Например, 604800 секунд (7 дней).

подсказка

Для нахождения оптимального количества активностей можно воспользоваться формулой a = V/(w*0.0025), где a — количество активностей на один воркспейс; V — желаемый объем памяти в ГБ, который будут занимать активности; 0.0025 — средний размер одной активности в ГБ; w — количество воркспейсов пользователей.

Файл ./cfg/platform.values.yaml:

• event_service.retention_events_count: количество хранящихся событий на один воркспейс.
• event_service.event_handler_period: частота проверки количества событий в базе. Значение задается в секундах. Например, 604800 секунд (7 дней).

подсказка

Для нахождения оптимального количества событий можно воспользоваться формулой e = V/(w*0.004), где e — количество событий на один воркспейс; V — желаемый объем памяти, который будут занимать события; 0.004 — средний размер одного события в ГБ; w — количество воркспейсов пользователей.

Отправка писем на SMTP-сервер

1. Остановите развернутую OMNI Platform:

   ./cli.sh platform uninstall

2. Внесите изменения в файле ./cfg/platform.secrets.json в platform-email-secret.

3. Пересоздайте секреты:

   ./cli.sh platform install-secrets

4. Заново разверните OMNI Platform:

   ./cli.sh platform install

Настройка оптимального количества соединений к БД

В этом разделе вы узнаете, как рассчитать количество соединений к БД для сервиса событий (platform-event-service-dep), и какие параметры на это влияют.

Почему важно контролировать количество соединений?

• Ограниченные ресурсы: Как сервис, так и БД имеют ограниченные ресурсы (оперативную память, процессорное время и т.д.). Если одновременно открыто слишком много соединений, это может перегрузить БД или сервис, что приведет к замедлению работы или даже сбоям.

• Оптимизация производительности: Слишком большое количество временных соединений может создать чрезмерную нагрузку на БД, в то время как недостаток соединений может привести к задержкам в обработке запросов.

• Удержание соединений: В некоторых случаях соединения могут оставаться открытыми на продолжительное время, особенно если сервис постоянно взаимодействует с БД. Например, если воркеры (процессы, которые выполняют задачи) активно работают, они могут удерживать соединения, чтобы быстрее выполнять последующие запросы.

Что произойдет, если не рассчитать количество соединений?

• Риск перегрузки базы данных: Если откроется слишком много соединений одновременно, БД может не справиться с нагрузкой, что приведет к снижению производительности.
• Риск замедления работы сервиса: В случаях, когда БД перегружена, обработка запросов может сильно замедлиться.
• Потенциальные сбои в работе: В крайнем случае, из-за недостатка ресурсов, могут происходить сбои, например, БД перестанет отвечать на запросы, или сервис начнет выдавать ошибки.

Формула для расчета количества соединений:

(W * (PS + MO)) + (PS + MO)

• Воркеры (W): Количество процессов или потоков, которые выполняют задачи в сервисе. Количество воркеров указывается в параметре event_service.workers в файле ./cfg/platform.values.yaml. Если количество не указано, то оно рассчитывается по формуле (количество ядер процессора * 2) + 1.
• Максимальное количество соединений в пуле (PS): Максимальное количество активных соединений, которые могут быть открыты одновременно. Значение указывается в параметре event_service.pool_size, и по умолчанию равно 5.
• Максимальное количество временных соединений (MO): Количество дополнительных соединений, которые могут быть открыты при высокой нагрузке, сверх тех, что указаны в пуле. Значение указывается в параметре event_service.max_overflow, и по умолчанию равно 10. Эти соединения существуют только до тех пор, пока нагрузка на сервис высокая.

Пример расчета

Допустим, у нас сервер с 8-ядерным процессором, и параметры настроек не изменялись. Тогда количество воркеров (W) равно (8 * 2) + 1 = 17. Подставляем значения в формулу и получаем:

((17) * (5 + 10)) + (5 + 10) = 270 соединений

Этот результат означает, что при пиковой нагрузке может быть открыто до 270 соединений к БД.

При нормальной работе можно не учитывать временные соединения (MO), т.е. получим такой результат:

((17) * 5) + 5 = 85 соединений

предупреждение

Не рекомендуется устанавливать значение 0 в параметре event_service.max_overflow, так как это может негативно сказаться на работе сервиса в условиях высокой нагрузки.