qdrant-memory-usage-optimization

Diagnostique et réduit l'utilisation de la mémoire de Qdrant. À utiliser lorsque quelqu'un signale « memory too high », « RAM keeps growing », « node crashed », « out of memory », « memory leak », ou demande « why is memory usage so high? », « how to reduce RAM? ». À utiliser également lorsque la mémoire ne correspond pas aux calculs, que la quantification n'a pas aidé, ou que les nœuds plantent pendant la récupération.

npx skills add https://github.com/qdrant/skills --skill qdrant-memory-usage-optimization

Comprendre l'utilisation de la mémoire

Qdrant fonctionne avec deux types de mémoire :

  • Mémoire résidente (aka RSSAnon) - mémoire utilisée pour les structures de données internes comme le suivi des ID, plus les composants qui doivent rester en RAM, tels que les vecteurs quantifiés quand always_ram=true et les index de payload.

  • Cache de pages du système d'exploitation - mémoire utilisée pour mettre en cache les lectures disque, qui peut être libérée si nécessaire. Les vecteurs originaux sont normalement stockés dans le cache de pages, donc le service ne s'arrêtera pas si la RAM est pleine, mais les performances peuvent se dégrader.

Il est normal que le cache de pages du système d'exploitation occupe toute la RAM disponible, mais si la mémoire résidente dépasse 80 % de la RAM totale, c'est un signe de problème.

Surveillance de l'utilisation de la mémoire

  • Qdrant expose l'utilisation de la mémoire via le point de terminaison /metrics. Voir Monitoring docs.

<!-- ToDo: Talk about memory usage of each components once API is available -->

Quelle quantité de mémoire est nécessaire pour Qdrant ?

L'utilisation optimale de la mémoire dépend du cas d'usage.

  • Pour les scénarios de recherche réguliers, des directives générales sont fournies dans Capacity planning docs.

Pour une ventilation détaillée de l'utilisation de la mémoire à grande échelle, voir Large scale memory usage example.

Les index de payload et le graphe HNSW nécessitent également de la mémoire, ainsi que les vecteurs eux-mêmes, il est donc important de les prendre en compte dans les calculs.

De plus, Qdrant nécessite de la mémoire supplémentaire pour les optimisations. Lors de l'optimisation, les segments optimisés sont entièrement chargés en RAM, il est donc important de laisser suffisamment de marge. Plus max_segment_size est grand, plus de marge est nécessaire.

Quand mettre l'index HNSW sur le disque

Placer les composants fréquemment utilisés (comme l'index HNSW) sur le disque peut causer une dégradation significative des performances. Il y a cependant des scénarios où cela peut être une bonne option :

  • Déploiements avec disques à faible latence - NVMe local ou similaire.
  • Déploiements multi-locataires, où seulement un sous-ensemble de locataires est fréquemment accessible, de sorte que seulement une fraction des données et de l'index est chargée en RAM à la fois.
  • Pour les déploiements avec inline storage activé.

Comment minimiser l'empreinte mémoire

Le principal défi est de placer sur le disque les parties de données qui sont rarement accessibles. Voici les principales techniques pour y parvenir :

  • Utiliser la quantification pour stocker uniquement les vecteurs compressés en RAM Quantization docs

  • Utiliser les types de données float16 ou int8 pour réduire l'utilisation de la mémoire des vecteurs respectivement de 2x ou 4x, avec un certain compromis sur la précision. En savoir plus sur les types de données de vecteurs dans la documentation

  • Exploiter Matryoshka Representation Learning (MRL) pour stocker uniquement de petits vecteurs en RAM tout en conservant de grands vecteurs sur le disque. Exemples d'utilisation de MRL avec l'inférence Qdrant Cloud : MRL docs

  • Pour les déploiements multi-locataires avec de petits locataires, les vecteurs peuvent être stockés sur le disque car les données du même locataire sont stockées ensemble Multitenancy docs

  • Pour les déploiements avec stockage local rapide et des exigences relativement faibles en termes de débit de recherche, il peut être possible de stocker tous les composants du magasin de vecteurs sur le disque. En savoir plus sur les implications de performance du stockage sur disque dans l'article

  • Pour les environnements à faible RAM, envisagez la configuration async_scorer, qui active le support de io_uring pour l'accès parallèle au disque, ce qui peut améliorer considérablement les performances du stockage sur disque. En savoir plus sur async_scorer dans l'article (disponible uniquement sur Linux avec kernel 5.11+)

  • Envisagez de stocker les vecteurs creux et le payload textuel sur le disque, car ils sont généralement plus adaptés au disque que les vecteurs denses.

  • Configurer les index de payload pour être stockés sur disque docs

  • Configurer les vecteurs creux pour être stockés sur disque docs