Перейти к основному содержимому
Версия: 1.18.0

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

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

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

  • 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

Изменение 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