Часто встречающиеся проблемы и пути их устранения#

Не удается открыть WAL метаданных коллекций#

При запуске экземпляра Platform V Vector DB (далее - Vector DB) в составе распределенной установки можно получить сообщение об ошибке следующего вида:

Can't open Collections meta Wal: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" }

Это означает, что Vector DB не может запуститься из-за того, что коллекция не загружается. Вероятно, связанные файлы WAL недоступны, так как они уже используются другим экземпляром Vector DB.

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

Созданный кластер позаботится о совместном использовании всех данных каждым узлом, самостоятельно размещая их в нужных местах. При использовании Kubernetes каждый узел должен иметь свой собственный том. При использовании Docker у каждого узла должен быть собственный смонтированный ресурс хранения или том. При прямом использовании Vector DB у каждого узла должен быть собственный каталог хранилища.

Ошибка доступности порта#

При получении сообщения Address already in use освободите порт 6333:

sudo lsof -i :6333 && kill <PID>

Уменьшение используемой памяти#

Основной источник использования памяти — это векторные данные. Есть несколько способов решить эту проблему:

  • настройте квантование, чтобы снизить потребление памяти векторами;

  • настройте хранение векторов на диске.

Выбор подхода зависит от требований. Подробная информация о настройке оптимального использования продукта приведена в разделе «Управление оптимизаторами» документа «Руководство прикладного разработчика».

Высокое использование памяти после настройки хранения векторов на диске#

Показатели использования памяти, сообщаемые top или htop, могут вводить в заблуждение. Они не показывают минимальное количество памяти, необходимое для работы сервиса. Если использование памяти RSS составляет 10 ГБ, это не означает, что он не будет работать на машине с 8 ГБ оперативной памяти.

Vector DB использует множество методов для уменьшения задержки при поиске, включая кеширование дисковых данных в оперативной памяти и предварительную загрузку данных с диска в оперативную память. В результате процесс Vector DB может использовать больше памяти, чем минимальный объем, необходимый для запуска службы.

Запросы очень медленные или завершаются тайм-аутом#

Возможны несколько причин такого поведения:

  • Использование фильтров без индекса полезной нагрузки — если выполняется поиск с фильтром, но нет индекса полезной нагрузки, Vector DB придется загружать всю полезную нагрузку из памяти диска для проверки условия фильтра. Убедитесь в правильной настройке индексов полезной нагрузки.

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

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

Совместимость#

Совместимость с процессорами CPU или GPU для векторных вычислений#

Vector DB в первую очередь полагается на ускорение работы центрального процессора для масштабируемости и эффективности. Также поддерживается ускоренная индексация на базе GPU у всех основных производителей оборудования.

Текущую версию предполагается запускать на серверах стандартной архитектуры. Использование GPU может значительно ускорить процесс построения векторных индексов, однако в процессе векторного поиска GPU не используется.

В дальнейшем, востребованность использования GPU в Vector DB будет уточняться отдельно.