Рекомендации

В данном разделе приводятся рекомендации для оптимальной работы с LUNA PLATFORM.

Оптимизация ресурсов

В данном разделе представлены советы по оптимизации ресурсов системы при работе с LUNA PLATFORM.

1. Убирать ненужные политики в обработчиках, включенные по умолчанию. Например, сохранение биометрических образцов и событий включено в обработчиках по умолчанию.

   Если сохранение не требуется, то необходимо их отключить. В противном случае необходимо следить и периодически удалять устаревшие данные, чтобы память сервера не заполнилась.

   Если включены эстимации, которые не требуются, то их выполнение будет увеличивать время выполнения каждого запроса.

2. Отключить использование ненужных сервисов.

3. Вместо увеличения количества экземпляров сервисов, увеличивать количество "рабочих процессов" (за исключением сервиса Remote SDK на GPU и Python Matcher).

4. Регулировать количество экземпляров/"рабочих процессов" Remote SDK и параметр "num_threads" (количество потоков "рабочего процесса") в настройках сервиса Remote SDK при работе на CPU.

   Как правило, значение параметра "num_threads" и количество экземпляров/"рабочих процессов" Remote SDK кратно числу физических ядер. Т.е. если есть 8 физических ядер, то рекомендуется использовать 2 экземпляра Remote SDK и "num_threads" = 4 для каждого экземпляра (2x4=8). Аналогично, если 24 ядра, то нужно 4 экземпляра Remote SDK и "num_threads" = 6 для каждого экземпляра (4x6=24).

   Следует помнить о том, что слишком большое количество экземпляров/"рабочих процессов" может негативно сказаться на производительности, поэтому не следует запускать 8 экземпляров/воркеров с "num_threads" = 1 при 8 доступных ядрах. Можно разделить количество ядер на 6 или 8 для определения количества экземпляров/"рабочих процессов".

   Параметр "num_threads" не влияет на работу на GPU.

5. При выполнении сравнения явно указывать необходимые поля "target".

   Например, если от результата сравнения не требуется ничего кроме "face_id", то нет смысла тратить ресурсы на использование остальных полей (поведение по умолчанию если не задать поля в "target").

   В рамках обработчиков в политике "match_policy" также указываются "targets", которые тоже необходимо настроить.

6. При небольших списках можно запускать больше экземпляров Python Matcher, уменьшая параметр "thread_count".

7. При больших списках более 1-2М не делать больше одного сервиса Python Matcher на одной NUMA-node.

8. Грамотно указывать лимит кандидатов и эталонов и не задавать больше чем нужно (см. настройку "PLATFORM_LIMITS" в настройках сервиса Python Matcher).

   Например, если нужно получить в ответе только одного кандидата с самой высокой схожестью, то не нужно указывать, что должно возвращаться top-3 кандидата.

9. Установить уровень логирования на "WARNING".

   Обратите внимание, что уменьшение уровня логирования может уменьшить потребление ресурсов, однако в случае возникновения проблем, данного уровня логов может быть недостаточно.

10. Использовать расписание задач для управления запуском задачи Garbage collection.

11. Использовать заголовки "Accept-Encoding" со значением "gzip, deflate" для оптимизации сетевого трафика при запросах к API при получении данных в формате JSON.

12. Уменьшать значение параметра "optimal_batch_size" в настройках сервиса Remote SDK при работе на CPU (значения разные для каждого эстиматора).

    При работе на CPU, параметр "optimal_batch_size" должен быть меньше, чем значение "num_threads". Например, если "num_threads" = 4, то рекомендуется выставлять "optimal_batch_size" <= 4.

    Как и в случае с "num_threads", оптимальное значение "optimal_batch_size" зависит от конкретной системы и характеристик задачи, поэтому его следует настраивать экспериментальным путем.

13. Не забывать указывать "image_type" равным "1" или 2" при отправке биометрических образцов лица или тела. По умолчанию значение равно "0" (необработанные изображения).

    Если оставить значение "0" , то выполняется повторное детектирование лица на изображении, что увеличивает время обработки запроса и может приводить к непредвиденным проблемам. Например, когда во frontend нашлось одно лицо, а в backend нашлось два лица, т. к. используются разные версии детекторов или разные настройки для детекции лиц.

14. Запускать Remote SDK только с определенными эстиматорами.

    Если какие-то эстиматоры не требуются для реализации бизнес-логики, то их можно отключить и удалить из контейнера, чтобы уменьшить потребление памяти.

15. Ознакомиться со разделом "Потребление ресурсов сервисами", чтобы подбирать под сервисы оптимальные серверы.

Продвинутая настройка PostrgeSQL

PostgreSQL можно настроить на эффективное взаимодействие с LUNA PLATFORM 5. Для этого необходимо задать определенные значения настройкам PostgreSQL в файле postgresql.conf.

В данном разделе не приводится полный список всех настроек с подробным описанием. См. полный перечень настроек с их описанием на официальном сайте PostgreSQL.

Полезные советы для расчета конфигурации PostgreSQL описаны здесь: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server.

Доступна возможность рассчитать конфигурацию для PostgreSQL исходя из максимальной производительности для заданной аппаратной конфигурации (см. https://pgtune.leopard.in.ua/).

Рекомендуемые значения для настроек

Примечание. Следует изменять нижеприведенные настройки с осторожностью, т.к. ручное изменение настроек PostgreSQL требует должный опыт.

Ниже приведены рекомендуемые значения настроек и их описание.

max_connections = 200 — задаёт максимальное количество одновременных подключений к серверу БД. По умолчанию равно 100.

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

В сервисе Configurator можно задать количество подключений к БД с помощью настройки connection_pool_size, расположенной в секциях LUNA_<SERVICE_NAME>_DB, где <SERVICE_NAME> — имя сервиса, имеющего базу данных. Реальное количество подключений может быть больше значения данной настройки на 1.

Если соединений слишком много, но мало активных, можно использовать сторонние сервисы для балансировки нагрузки, например, haproxy или pgbouncer. При использовании сервисов балансировки необходимо учитывать некоторые нюансы, описанные здесь: https://magicstack.github.io/asyncpg/current/faq.html#why-am-i-getting-prepared-statement-errors.

maintenance_work_mem = 2GB — задаёт максимальный объём памяти для операций обслуживания БД.

shared_buffers = 0.25…0.5 * RAM (MB) — определяет, сколько памяти будет выделяться Postgres для кеширования данных. Зависит от того, как часто выполняется сравнение по БД, какие индексы и т.п.

effective_io_concurrency = 100 — задаёт допустимое число параллельных операций ввода/вывода, которое говорит Postgres о том, сколько операций ввода/вывода могут быть выполнены одновременно. Чем больше это число, тем больше операций ввода/вывода будет пытаться выполнить параллельно PostgreSQL в отдельном сеансе.

max_worker_processes = CPU_COUNT (количество ядер процессора) — задаёт максимальное число фоновых процессов, которые можно запустить в текущей системе.

max_parallel_maintenance_workers = 4 — задаёт максимальное число параллельных рабочих процессов, выполняющих команду создания индекса (CREATE INDEX).

max_parallel_workers_per_gather = 4 — задаёт максимальное число рабочих процессов, на которые может быть распараллелен запрос или подзапрос.

max_parallel_workers = CPU_COUNT (количество ядер процессора) — задаёт максимальное число рабочих процессов, которое система сможет поддерживать для параллельных операций.

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

enable_bitmapscan = off — включает или отключает использование bitmapscan. Иногда может понадобится, когда PostgreSQL по ошибке определяет, что bitmapscan лучше индекса. Изменять рекомендуется только при необходимости, когда предполагается, что запрос будет использовать индекс, но по неизвестным причинам не использует.

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

random_page_cost = 1.5 — задаёт приблизительную стоимость чтения одной произвольной страницы с диска.

parallel_tuple_cost = 0.1 — задаёт приблизительную стоимость передачи одного кортежа (строки) от параллельного рабочего процесса другому процессу.

parallel_setup_cost = 5000.0 — задаёт приблизительную стоимость запуска параллельных рабочих процессов.

max_parallel_workers_per_gather = CPU_COUNT (количество ядер процессора) / 2 — задаёт максимальное число рабочих процессов, на которые может быть распараллелен запрос или подзапрос.

min_parallel_table_scan_size = 1MB — задаёт минимальный объем данных таблицы, подлежащий сканированию, при котором может применяться параллельное сканирование.

min_parallel_index_scan_size = 8k — задаёт минимальный объем индексных данных для параллельного сканирования.

effective_cache_size = 75% от RAM — определяет ожидаемый объем оперативной памяти, который может быть использован для кэширования данных в базе данных.