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

Полный список параметров конфигурации

В этом разделе перечислены все настройки, которые могут быть использованы для конфигурации системы.

Файл конфигурации	Переменные
./cfg/platform.secrets.json	docker-registry — установите значения, если используется внешний docker-registry. rabbit-secret — имя пользователя и пароль для доступа к брокеру сообщений, используется для внутреннего взаимодействия сервисов OMNI Platform. Задайте произвольное имя, состоящее из латинских букв, без пробелов и пароль, состоящий из латинских букв и цифр, без пробелов. postgres-root-credentials — имя пользователя и пароль для root пользователя в базе данных. platform-service-key — секретный ключ, необходимый для внутреннего взаимодействия сервисов OMNI Platform. platform-user-secret — учетные данные (электронная почта и пароль), которые будут использоваться для доступа в OMNI Platform. При первом развертывании пользователи будут созданы автоматически. Указываемый адрес электронной почты должен состоять из цифр, латинских букв и символов. platform-email-secret — параметры SMTP-сервера. Чтобы отключить отправку писем, оставьте данные поля пустыми. minio-credentials — имя пользователя и пароль для root пользователя в объектном хранилище.
./cfg/platform.values.yaml	backend.query_limit — ограничение количества возвращаемых элементов в API-запросах для получения сущностей системы. Увеличение данного лимита не рекомендуется, т.к. время выполнения API-запроса может увеличиться в несколько раз. Также обратите внимание, что увеличение лимитов приведет к ухудшению работы системы. backend.index_update_period — значение в секундах, описывающее через какое время добавленный профиль появится в поисковом индексе. По умолчанию установлено значение 60 секунд. Если требуется увеличить скорость обновления поискового индекса, следует уменьшить значение. backend.enable_profile_autogeneration — Автосоздание профилей для приходящих активностей с OMNI Agent. Необходимо учитывать, что при включении данной опции будет увеличенный расход ресурсов лицензии (размер базы данных). Для включения функции установить значение 1. processing.use_cuda — отвечает за использование видеокарты в сервисе обработки. 0 — отключить, 1 — включить. postgres.enable — выключите, если используете свой сервер базы данных. Примечание. Необходимо поменять значения для postgres-root-credentials в файле ./cfg/platform.secrets.json и значения для postgres.host и postgres.port в текущем файле. minio.enable — обозначает, что для хранения изображений из событий будет использоваться объектное хранилище. Если выключить этот параметр, для хранения изображений будет использоваться postgres. Примечание. Если после первого развертывания уже накопилось какое-то количество изображений, то выключать данный параметр не рекомендуется, иначе будет невозможно получить накопленные данные. При разветывании в AWS необходимо отключить этот параметр. minio.buckets_prefix — обозначает префикс всех бакетов, которые будут использоваться модулем в minio в формате <префикс>.<название бакета>. Если префикс не требуется, оставьте строку пустой. Примечание. Если требуется сохранить данные в minio с прошлой версии, также оставьте строку пустой. matcher.shard_n — интерфейсный параметр, регулирует количество одновременных обращений к matcher-serivice. Должен быть равен параметру shard.quantity в файле matcher.values.yaml event_service.pool_size — максимальное количество активных и неактивных соединений в пуле, которые может использовать один воркер. event_service.max_overflow — максимальное количество временных соединений, которые могут быть открыты сверх значения параметра event-service.pool_size. Подробнее см. в разделе Настройка оптимального количества соединений к БД. event_service.pool_recycle — время в секундах, через которое соединения из пула должны быть переоткрыты. event_service.pool_pre_ping — параметр, включающий или отключающий проверку соединения с БД перед отправкой запросов. Обратите внимание: Данный параметр отвечает за проверку соединений со стороны сервиса, обработка со стороны БД настраивается отдельно. event_service.ws_timeout — время в секундах, после которого веб-сокет соединение будет закрыто при обрывах. event_service.bucket_names — названия бакетов, которые будет использовать сервис событий. Примечание. Не меняйте названия бакетов, если требуется сохранить данные с прошлой версии.
./cfg/matcher.values.yaml	shard.quantity — количество создаваемых шардов, увеличение параметра позволяет ускорять поиск на больших данных shard.search_threads_n — количество используемых потоков для выполнения поиска

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

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

• 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, так как это может негативно сказаться на работе сервиса в условиях высокой нагрузки.