Dépannage d'un ralentissement de la recherche après la mise à jour de Milvus : leçons de l'équipe WPS

Ce billet a été rédigé par l'équipe d'ingénieurs WPS de Kingsoft Office Software, qui utilise Milvus dans un système de recommandation. Lors de leur mise à jour de Milvus 2.2.16 à 2.5.16, la latence de recherche a augmenté de 3 à 5 fois. Cet article explique comment ils ont étudié le problème et l'ont résolu, et peut être utile à d'autres membres de la communauté qui prévoient une mise à niveau similaire.

Pourquoi nous avons mis à jour Milvus

Nous faisons partie de l'équipe d'ingénieurs de WPS qui développe des logiciels de productivité, et nous utilisons Milvus comme moteur de recherche vectoriel derrière la recherche de similarité en temps réel dans notre système de recommandation en ligne. Notre cluster de production stockait des dizaines de millions de vecteurs, avec une dimension moyenne de 768. Les données étaient servies par 16 QueryNodes, et chaque pod était configuré avec des limites de 16 cœurs de CPU et 48 Go de mémoire.

Lors de l'exécution de Milvus 2.2.16, nous avons rencontré un grave problème de stabilité qui affectait déjà l'entreprise. En cas de forte concurrence des requêtes, planparserv2.HandleCompare pouvait provoquer une exception de pointeur nul, ce qui entraînait une panique du composant Proxy et des redémarrages fréquents. Ce bogue était très facile à déclencher dans des scénarios de forte concurrence et affectait directement la disponibilité de notre service de recommandation en ligne.

Vous trouverez ci-dessous le journal des erreurs du Proxy et la trace de pile de l'incident :

[2025/12/23 10:43:13.581 +00:00] [ERROR] [concurrency/pool_option.go:53] ["Conc pool panicked"]
[panic="runtime error: invalid memory address or nil pointer dereference"]
[stack="...
github.com/milvus-io/milvus/internal/parser/planparserv2.HandleCompare
  /go/src/github.com/milvus-io/milvus/internal/parser/planparserv2/utils.go:331
github.com/milvus-io/milvus/internal/parser/planparserv2.(*ParserVisitor).VisitEquality
  /go/src/github.com/milvus-io/milvus/internal/parser/planparserv2/parser_visitor.go:345
...
github.com/milvus-io/milvus/internal/proxy.(*queryTask).PreExecute
  /go/src/github.com/milvus-io/milvus/internal/proxy/task_query.go:271
github.com/milvus-io/milvus/internal/proxy.(*taskScheduler).processTask
  /go/src/github.com/milvus-io/milvus/internal/proxy/task_scheduler.go:455
..."]
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x2f1a02a]
goroutine 989 [running]:
github.com/milvus-io/milvus/internal/parser/planparserv2.HandleCompare(…)
/go/src/github.com/milvus-io/milvus/internal/parser/planparserv2/utils.go:331 +0x2a
github.com/milvus-io/milvus/internal/parser/planparserv2.(*ParserVisitor).VisitEquality(…)
/go/src/github.com/milvus-io/milvus/internal/parser/planparserv2/parser_visitor.go:345 +0x7e5

Ce que montre la trace de pile: La panique s'est produite pendant le prétraitement de la requête dans Proxy, à l'intérieur de queryTask.PreExecute. Le chemin d'appel était le suivant :

taskScheduler.processTask → queryTask.PreExecute → planparserv2.CreateRetrievePlan → planparserv2.HandleCompare

L'incident s'est produit lorsque HandleCompare a tenté d'accéder à une mémoire non valide à l'adresse 0x8, ce qui a déclenché un SIGSEGV et entraîné l'interruption du processus Proxy.

Pour éliminer complètement ce risque de stabilité, nous avons décidé de mettre à niveau le cluster de Milvus 2.2.16 à 2.5.16.

Sauvegarde des données avec milvus-backup avant la mise à niveau

Avant de toucher au cluster de production, nous avons tout sauvegardé à l'aide de l'outil officiel milvus-backup. Il prend en charge la sauvegarde et la restauration au sein d'un même cluster, entre clusters et entre versions de Milvus.

Vérification de la compatibilité des versions

milvus-backup a deux règles de version pour les restaurations inter-version:

1. Le cluster cible doit exécuter la même version de Milvus ou une version plus récente. Une sauvegarde de la version 2.2 peut être chargée dans la version 2.5, mais pas l'inverse.

2. La cible doit être au moins Milvus 2.4. Les cibles de restauration plus anciennes ne sont pas prises en charge.

Notre chemin (sauvegarde à partir de la version 2.2.16, chargement dans la version 2.5.16) satisfait aux deux règles.

Sauvegarde de ↓ \NRestauration vers →	2.4	2.5	2.6
2.2	✅	✅	✅
2.3	✅	✅	✅
2.4	✅	✅	✅
2.5	❌	✅	✅
2.6	❌	❌	✅

Fonctionnement de Milvus-Backup

Milvus Backup facilite la sauvegarde et la restauration des métadonnées, des segments et des données dans les instances Milvus. Il fournit des interfaces vers le nord, telles qu'une CLI, une API et un module Go basé sur gRPC, pour une manipulation flexible des processus de sauvegarde et de restauration.

Milvus Backup lit les métadonnées et les segments de la collection à partir de l'instance Milvus source pour créer une sauvegarde. Il copie ensuite les données de collecte à partir du chemin racine de l'instance Milvus source et les enregistre dans le chemin racine de la sauvegarde.

Pour restaurer à partir d'une sauvegarde, Milvus Backup crée une nouvelle collection dans l'instance Milvus cible en fonction des métadonnées de la collection et des informations sur les segments dans la sauvegarde. Il copie ensuite les données de sauvegarde du chemin racine de la sauvegarde vers le chemin racine de l'instance cible.

Exécution de la sauvegarde

Nous avons préparé un fichier de configuration dédié, configs/backup.yaml. Les principaux champs sont indiqués ci-dessous, les valeurs sensibles ayant été supprimées :

milvus:
  address: 1.1.1.1  # Source Milvus address
  port: 19530  # Source Milvus port
  user: root  # Source Milvus username (must have backup permissions)
  password: <PASS> # Source Milvus user password
etcd:
endpoints: “2.2.2.1:2379,2.2.2.2:2379,2.2.2.3:2379” # Endpoints of the etcd cluster connected to Milvus
rootPath: “by-dev”  # Prefix of Milvus metadata in etcd. If not modified, the default is by-dev. It is recommended to check etcd before proceeding.
minio:
# Source Milvus object storage bucket configuration
storageType: “aliyun” # support storage type: local, minio, s3, aws, gcp, ali(aliyun), azure, tc(tencent), gcpnative
address: ks3-cn-beijing-internal.ksyuncs.com # Address of MinIO/S3
port: 443   # Port of MinIO/S3
accessKeyID: object storage AK>

secretAccessKey: object storage SK>
useSSL: true
bucketName: “”
rootPath: “file” # Root directory prefix under the source object storage bucket where the current Milvus data is stored. If Milvus is installed using Helm Chart, the default prefix is file. It is recommended to log in to the object storage and verify before proceeding.
# Object storage bucket configuration for storing backup data
backupStorageType: “aliyun” # support storage type: local, minio, s3, aws, gcp, ali(aliyun), azure, tc(tencent)
backupAddress: ks3-cn-beijing-internal.ksyuncs.com # Address of MinIO/S3
backupPort: 443   # Port of MinIO/S3
backupAccessKeyID: 
backupSecretAccessKey: 
backupBucketName: 
backupRootPath: “backup” # Root path to store backup data. Backup data will be stored in backupBucketName/backupRootPath
backupUseSSL: true # Access MinIO/S3 with SSL
crossStorage: “true”  # Must be set to true when performing cross-storage backup

Nous avons ensuite exécuté cette commande :

# Create a backup using milvus-backup
./milvus-backup create --config configs/backup.yaml -n backup_v2216

milvus-backup La sauvegarde à chaud prend en charge la sauvegarde à chaud, de sorte qu'elle n'a généralement que peu d'impact sur le trafic en ligne. Il est préférable d'exécuter la sauvegarde pendant les heures creuses afin d'éviter la saturation des ressources.

Vérification de la sauvegarde

Une fois la sauvegarde terminée, nous avons vérifié qu'elle était complète et utilisable. Nous avons principalement vérifié si le nombre de collections et de segments dans la sauvegarde correspondait à ceux du cluster source.

./milvus-backup list --config configs/backup.yaml
# View backup details and confirm the number of Collections and Segments
./milvus-backup get --config configs/backup.yaml -n backup_v2216

Comme ils correspondaient, nous sommes passés à la mise à niveau.

Mise à jour avec Helm Chart

Le saut de trois versions majeures (2.2 → 2.5) avec des dizaines de millions de vecteurs rendait une mise à niveau sur place trop risquée. Nous avons donc construit un nouveau cluster et y avons migré les données. L'ancien cluster est resté en ligne pour le retour en arrière.

Déploiement du nouveau cluster

Nous avons déployé le nouveau cluster Milvus 2.5.16 avec Helm :

# Add the Milvus Helm repository
: helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update  
# Check the Helm chart version corresponding to the target Milvus version
: helm search repo milvus/milvus -l | grep 2.5.16
milvus/milvus        4.2.58               2.5.16                    Milvus is an open-source vector database built ...
# Deploy the new version cluster (with mmap disabled)
helm install milvus-v25 milvus/milvus 

–namespace milvus-new 

–values values-v25.yaml 

–version 4.2.58 

–wait

Changements de configuration clés (values-v25.yaml)

Pour que la comparaison des performances soit équitable, nous avons fait en sorte que le nouveau cluster soit aussi similaire que possible à l'ancien. Nous n'avons modifié que quelques paramètres importants pour cette charge de travail :

• Désactiver Mmap (mmap.enabled: false) : Notre charge de travail de recommandation est sensible à la latence. Si Mmap est activé, certaines données peuvent être lues sur le disque lorsque cela est nécessaire, ce qui peut ajouter un délai d'E/S sur le disque et provoquer des pics de latence. Nous l'avons désactivé pour que les données restent entièrement en mémoire et que la latence des requêtes soit plus stable.

• Nombre de QueryNodes : 16, comme dans l'ancien cluster.

• Limites de ressources : chaque Pod dispose toujours de 16 cœurs de CPU, comme dans l'ancien cluster.

Conseils pour les mises à niveau de versions majeures :

• Construisez un nouveau cluster au lieu de procéder à une mise à niveau sur place. Vous évitez ainsi les risques liés à la compatibilité des métadonnées et conservez un chemin de retour en arrière propre.

• Vérifiez votre sauvegarde avant de procéder à la migration. Une fois que les données sont au format de la nouvelle version, il est difficile de revenir en arrière.

• Maintenez les deux clusters en fonctionnement pendant le basculement. Déplacez progressivement le trafic et ne mettez l'ancien cluster hors service qu'après une vérification complète.

Migration des données après la mise à niveau avec Milvus - Restauration de la sauvegarde

Nous avons utilisé milvus-backup restore pour charger la sauvegarde dans le nouveau cluster. Dans la terminologie de milvus-backup, "restaurer" signifie "charger les données de sauvegarde dans un cluster cible". La cible doit exécuter la même version de Milvus ou une version plus récente. Ainsi, malgré le nom, les restaurations font toujours avancer les données.

Exécution de la restauration

Le fichier de configuration de la restauration, configs/restore.yaml, devait pointer vers le nouveau cluster et ses paramètres de stockage. Les champs principaux ressemblent à ceci :

# Restore target Milvus connection information
milvus:
  address: 1.1.1.1  # Milvus address
  port: 19530  # Milvus port
  user: root  # Milvus username (must have restore permissions)
  password: <PASS> # Milvus user password  
  etcd:
    endpoints: "2.2.2.1:2379,2.2.2.2:2379,2.2.2.3:2379" # Endpoints of the etcd cluster connected to the target Milvus
    rootPath: "by-dev"  # Prefix of Milvus metadata in etcd. If not modified, the default is by-dev. It is recommended to check etcd before proceeding.
minio:
# Target Milvus object storage bucket configuration
storageType: “aliyun” # support storage type: local, minio, s3, aws, gcp, ali(aliyun), azure, tc(tencent), gcpnative
address: ks3-cn-beijing-internal.ksyuncs.com # Address of MinIO/S3
port: 443   # Port of MinIO/S3
accessKeyID: