Resolução de problemas de lentidão na pesquisa após a atualização do Milvus: Lições da equipa WPS
Resolução de problemas de lentidão na pesquisa após a atualização do Milvus: Lições da equipa WPS
Engineering
March 18, 2026the WPS engineering team
Este post foi contribuído pela equipa de engenharia WPS da Kingsoft Office Software, que utiliza o Milvus num sistema de recomendação. Durante a atualização do Milvus 2.2.16 para o 2.5.16, a latência da pesquisa aumentou 3 a 5 vezes. Este artigo explica como investigaram o problema e o resolveram, e pode ser útil para outros na comunidade que planeiam uma atualização semelhante.
Por que atualizamos o Milvus
Fazemos parte da equipa de engenharia da WPS que desenvolve software de produtividade e utilizamos o Milvus como o motor de pesquisa vetorial por detrás da pesquisa de semelhanças em tempo real no nosso sistema de recomendação online. O nosso cluster de produção armazenava dezenas de milhões de vectores, com uma dimensão média de 768. Os dados foram servidos por 16 QueryNodes, e cada pod foi configurado com limites de 16 núcleos de CPU e 48 GB de memória.
Durante a execução do Milvus 2.2.16, deparámo-nos com um grave problema de estabilidade que já estava a afetar o negócio. Sob alta simultaneidade de consultas, planparserv2.HandleCompare poderia causar uma exceção de ponteiro nulo, fazendo com que o componente Proxy entrasse em pânico e reiniciasse frequentemente. Este erro era muito fácil de ativar em cenários de elevada concorrência e afectava diretamente a disponibilidade do nosso serviço de recomendação online.
Abaixo está o registo de erros do Proxy e o stack trace do incidente:
O que o rastreamento de pilha mostra: O pânico ocorreu durante o pré-processamento da consulta no Proxy, em queryTask.PreExecute. O caminho da chamada foi:
A falha ocorreu quando HandleCompare tentou aceder a uma memória inválida no endereço 0x8, desencadeando um SIGSEGV e causando a falha do processo Proxy.
Para eliminar completamente este risco de estabilidade, decidimos atualizar o cluster do Milvus 2.2.16 para o 2.5.16.
Fazendo backup dos dados com milvus-backup antes da atualização
Antes de tocar no cluster de produção, fizemos o backup de tudo usando a ferramenta oficial milvus-backup. Ela suporta backup e restauração dentro do mesmo cluster, entre clusters e entre versões do Milvus.
Verificando a compatibilidade de versões
O milvus-backup tem duas regras de versão para restaurações entre versões:
O cluster de destino deve executar a mesma versão do Milvus ou uma mais recente. Um backup da versão 2.2 pode ser carregado na versão 2.5, mas não o contrário.
O destino deve ser, no mínimo, o Milvus 2.4. Alvos de restauração mais antigos não são suportados.
Nosso caminho (backup da 2.2.16, carregar na 2.5.16) satisfez ambas as regras.
Cópia de segurança de ↓ \ Restaurar para →
2.4
2.5
2.6
2.2
✅
✅
✅
2.3
✅
✅
✅
2.4
✅
✅
✅
2.5
❌
✅
✅
2.6
❌
❌
✅
Como funciona o Milvus-Backup
O Milvus Backup facilita o backup e a restauração de metadados, segmentos e dados nas instâncias do Milvus. Fornece interfaces para o norte, como uma CLI, uma API e um módulo Go baseado em gRPC, para uma manipulação flexível dos processos de backup e restauração.
O Milvus Backup lê os metadados e segmentos da coleção a partir da instância de origem do Milvus para criar uma cópia de segurança. Depois copia os dados da coleção do caminho raiz da instância Milvus de origem e guarda-os no caminho raiz da cópia de segurança.
Para restaurar a partir de uma cópia de segurança, o Milvus Backup cria uma nova coleção na instância de destino do Milvus com base nos metadados da coleção e na informação do segmento na cópia de segurança. Em seguida, copia os dados de backup do caminho raiz do backup para o caminho raiz da instância de destino.
Executar a cópia de segurança
Preparámos um ficheiro de configuração dedicado, configs/backup.yaml. Os campos principais são mostrados abaixo, com os valores sensíveis removidos:
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
Em seguida, executamos este comando:
# Create a backup using milvus-backup
./milvus-backup create --config configs/backup.yaml -n backup_v2216
milvus-backup suporta backup a quente, por isso normalmente tem pouco impacto no tráfego online. A execução durante as horas de menor movimento é ainda mais segura para evitar a contenção de recursos.
Verificando o backup
Após a conclusão do backup, verificámos se estava completo e utilizável. Verificamos principalmente se o número de coleções e segmentos no backup correspondia aos do cluster de origem.
./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
Eles corresponderam, então passamos para a atualização.
Atualização com o Helm Chart
Saltar três versões principais (2.2 → 2.5) com dezenas de milhões de vetores tornou uma atualização no local muito arriscada. Em vez disso, criamos um novo cluster e migramos os dados para ele. O cluster antigo permaneceu online para reversão.
Implementando o novo cluster
Implementámos o novo cluster Milvus 2.5.16 com o 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.582.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
Principais alterações de configuração (values-v25.yaml)
Para tornar a comparação de desempenho justa, mantivemos o novo cluster o mais parecido possível com o antigo. Alteramos apenas algumas configurações que eram importantes para essa carga de trabalho:
Desativar o Mmap (mmap.enabled: false): Nossa carga de trabalho de recomendação é sensível à latência. Se o Mmap estiver ativado, alguns dados podem ser lidos do disco quando necessário, o que pode aumentar o atraso de E/S do disco e causar picos de latência. Nós o desativamos para que os dados permaneçam totalmente na memória e a latência da consulta seja mais estável.
Contagem de QueryNodes: mantida em 16, igual à do cluster antigo
Limites de recursos: cada Pod ainda tinha 16 núcleos de CPU, o mesmo que o cluster antigo
Dicas para atualizações de versões principais:
Construir um novo cluster em vez de atualizar no local. Você evita riscos de compatibilidade de metadados e mantém um caminho de reversão limpo.
Verifique seu backup antes de migrar. Uma vez que os dados estejam no formato da nova versão, não é possível voltar atrás facilmente.
Mantenha os dois clusters em execução durante a transição. Desloque o tráfego gradualmente e só desactive o cluster antigo após uma verificação completa.
Migração de dados após a atualização com o Milvus-Backup Restore
Usamos milvus-backup restore para carregar o backup no novo cluster. Na terminologia do milvus-backup, "restaurar" significa "carregar dados de backup em um cluster de destino". O destino deve executar a mesma versão do Milvus ou uma mais recente, portanto, apesar do nome, as restaurações sempre movem os dados para frente.
Executando a restauração
O arquivo de configuração da restauração, configs/restore.yaml, tinha que apontar para o novo cluster e suas configurações de armazenamento. Os campos principais eram assim:
# 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:
# 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
restore.yaml precisa das informações de conexão Milvus e MinIO do novo cluster para que os dados restaurados sejam gravados no armazenamento do novo cluster.
Verificações após a restauração
Após a conclusão da restauração, verificamos quatro coisas para garantir que a migração estava correta:
Esquema. O esquema de coleção no novo cluster tinha de corresponder exatamente ao antigo, incluindo definições de campo e dimensões de vetor.
Contagem total de linhas. Comparámos o número total de entidades nos clusters antigo e novo para garantir que não se perdiam dados.
Status do índice. Confirmámos que todos os índices tinham terminado a construção e que o seu estado estava definido para Finished.
Resultados da consulta. Executámos as mesmas consultas em ambos os clusters e comparámos as IDs devolvidas e as pontuações de distância para nos certificarmos de que os resultados coincidiam.
Mudança gradual de tráfego e a surpresa da latência
Transferimos o tráfego de produção para o novo cluster em fases:
Fase
Partilha de tráfego
Duração
O que observámos
Fase 1
5%
24 horas
Latência da consulta P99, taxa de erro e exatidão dos resultados
Fase 2
25%
48 horas
Latência da consulta P99/P95, QPS, utilização da CPU
Fase 3
50%
48 horas
Métricas de ponta a ponta, utilização de recursos
Fase 4
100%
Monitorização contínua
Estabilidade geral das métricas
Mantivemos o cluster antigo a funcionar durante todo o tempo para um rollback instantâneo.
Durante esta implementação, detectámos o problema: a latência da pesquisa no novo cluster v2.5.16 era 3-5 vezes superior à do antigo cluster v2.2.16.
Encontrando a causa da lentidão da pesquisa
Etapa 1: verificar o uso geral da CPU
Começamos com o uso da CPU por componente para ver se o cluster estava com poucos recursos.
Componente
Uso da CPU (núcleos)
Análise
Nó de consulta
10.1
O limite era de 16 núcleos, pelo que a utilização foi de cerca de 63%. Não totalmente utilizado
Proxy
0.21
Muito baixo
MixCoord
0.11
Muito baixo
DataNode
0.14
Muito baixo
IndexNode
0.02
Muito baixo
Isso mostrou que o QueryNode ainda tinha CPU suficiente disponível. Portanto, a desaceleração não foi causada pela falta geral de CPU.
Etapa 2: verificar o equilíbrio do QueryNode
A CPU total parecia boa, mas os pods individuais do QueryNode tinham um desequilíbrio claro:
Pod do QueryNode
Uso da CPU (último)
Uso da CPU (máximo)
querynode-pod-1
8.38%
9.91%
querynode-pod-2
5.34%
6.85%
querinode-pod-3
4.37%
6.73%
querinode-pod-4
4.26%
5.89%
querinode-pod-5
3.39%
4.82%
querinode-pod-6
3.97%
4.56%
querinode-pod-7
2.65%
4.46%
querynode-pod-8
2.01%
3.84%
querinode-pod-9
3.68%
3.69%
O pod-1 usou quase 5x mais CPU que o pod-8. Isso é um problema porque o Milvus distribui uma consulta para todos os QueryNodes e espera que o mais lento termine. Alguns pods sobrecarregados estavam a arrastar para baixo todas as pesquisas.
Etapa 3: Comparar a distribuição do segmento
A carga irregular geralmente indica uma distribuição de dados irregular, portanto, comparamos os layouts de segmento entre os clusters antigos e novos.
Layout do segmento v2.2.16 (13 segmentos no total)
Intervalo de contagem de linhas
Contagem de segmentos
Estado
740,000 ~ 745,000
12
Selado
533,630
1
Selado
O cluster antigo era bastante uniforme. Ele tinha apenas 13 segmentos, e a maioria deles tinha cerca de 740.000 linhas.
Layout do segmento v2.5.16 (21 segmentos no total)
Intervalo de contagem de linhas
Contagem de segmentos
Estado
680,000 ~ 685,000
4
Selado
560,000 ~ 682,550
5
Selado
421,575 ~ 481,800
4
Selado
358,575 ~ 399,725
4
Selado
379,650 ~ 461,725
4
Selado
O novo cluster tinha um aspeto muito diferente. Ele tinha 21 segmentos (60% a mais), com tamanho de segmento variável: alguns tinham ~685k linhas, outros apenas 350k. A restauração havia espalhado os dados de forma desigual.
Causa principal
Nós rastreamos o problema até o nosso comando de restauração original:
Esse sinalizador --use_v2_restore habilita o modo de restauração de mesclagem de segmentos, que agrupa vários segmentos em um único trabalho de restauração. Esse modo foi projetado para acelerar as restaurações quando há muitos segmentos pequenos.
Mas em nossa restauração de versão cruzada (2.2 → 2.5), a lógica v2 reconstruiu os segmentos de forma diferente do cluster original: ela dividiu segmentos grandes em segmentos menores e de tamanho desigual. Uma vez carregados, alguns QueryNodes ficaram presos com mais dados do que outros.
Isso prejudicava o desempenho de três maneiras:
Nós quentes: Os QueryNodes com segmentos maiores ou mais tinham que trabalhar mais
Efeito do nó mais lento: a latência da consulta distribuída depende do nó mais lento
Mais sobrecarga de mesclagem: mais segmentos também significavam mais trabalho ao mesclar resultados
A correção
Removemos --use_v2_restore e restauramos com a lógica padrão:
Primeiro, limpamos os dados incorretos do novo cluster e, em seguida, executamos a restauração padrão. A distribuição dos segmentos voltou ao equilíbrio, a latência da pesquisa voltou ao normal e o problema desapareceu.
O que faríamos de diferente na próxima vez
Nesse caso, demoramos muito tempo para encontrar o problema real: distribuição desigual de segmentos. Aqui está o que teria tornado isso mais rápido.
Melhorar o monitoramento dos segmentos
O Milvus não expõe a contagem de segmentos, a distribuição de linhas ou a distribuição de tamanho por coleção nos painéis padrão do Grafana. Tivemos que vasculhar manualmente o Attu e o etcd, o que foi lento.
Seria útil adicionar:
um painel de distribuição de segmentos no Grafana, mostrando quantos segmentos cada QueryNode carregou, além de suas contagens de linhas e tamanhos
um alerta de desequilíbrio, acionado quando as contagens de linhas de segmentos nos nós ultrapassam um limite
uma visualização de comparação de migração, para que os usuários possam comparar a distribuição de segmentos entre os clusters antigos e novos após uma atualização
Usar uma lista de verificação de migração padrão
Verificámos a contagem de linhas e considerámo-la boa. Isso não foi suficiente. Uma validação completa pós-migração também deve abranger:
Consistência do esquema. As definições de campo e as dimensões do vetor correspondem?
Contagem de segmentos. O número de segmentos mudou drasticamente?
Equilíbrio do segmento. A contagem de linhas entre segmentos é razoavelmente uniforme?
Status do índice. Todos os índices são finished?
Referência de latência. As latências de consulta P50, P95 e P99 são semelhantes às do cluster antigo?
Equilíbrio de carga. O uso da CPU do QueryNode é distribuído uniformemente entre os pods?
Adicionar verificações automatizadas
Você pode criar um script dessa validação com o PyMilvus para capturar o desequilíbrio antes que ele atinja a produção:
from pymilvus import connections, utility, Collection
defcheck_segment_balance(collection_name: str):
"""Check Segment distribution balance"""
collection = Collection(collection_name)
segments = utility.get_query_segment_info(collection_name)
# Group statistics by QueryNode
node_stats = {}
for seg in segments:
node_id = seg.nodeID
if node_id notin node_stats:
node_stats[node_id] = {"count": 0, "rows": 0}
node_stats[node_id]["count"] += 1
node_stats[node_id]["rows"] += seg.num_rows
# Calculate balance
row_counts = [v["rows"] for v in node_stats.values()]
avg_rows = sum(row_counts) / len(row_counts)
max_deviation = max(abs(r - avg_rows) / avg_rows for r in row_counts)
print(f"Number of nodes: {len(node_stats)}")
print(f"Average row count: {avg_rows:.0f}")
print(f"Maximum deviation: {max_deviation:.2%}")
if max_deviation > 0.2: # Raise a warning if deviation exceeds 20%print("⚠️ Warning: Segment distribution is unbalanced and may affect query performance!")
for node_id, stats insorted(node_stats.items()):
print(f" Node {node_id}: {stats['count']} segments, {stats['rows']} rows")
# Usage example
connections.connect(host=“localhost”, port=“19530”)
check_segment_balance(“your_collection_name”)
Usar melhor as ferramentas existentes
Algumas ferramentas já suportam diagnósticos em nível de segmento:
Birdwatcher: pode ler os metadados Etcd diretamente e mostrar a disposição dos segmentos e a atribuição de canais
Milvus Web UI (v2.5+): permite inspecionar visualmente as informações do segmento
Grafana + Prometheus: pode ser usado para criar painéis personalizados para monitoramento de cluster em tempo real
Sugestões para a comunidade Milvus
Algumas mudanças no Milvus tornariam esse tipo de solução de problemas mais fácil:
Explicar a compatibilidade de parâmetros de forma mais claraOsdocumentos do milvus-backup devem explicar claramente como opções como --use_v2_restore se comportam durante restaurações entre versões e os riscos que podem introduzir.
Adicionar melhores verificações após a restauraçãoApós aconclusão do restore, seria útil se a ferramenta imprimisse automaticamente um resumo da distribuição do segmento.
Expor métricas relacionadas ao equilíbrioAsmétricasdo Prometheusdevem incluir informações de equilíbrio do segmento, para que os usuários possam monitorá-las diretamente.
Apoiar a análise do plano de consultaSemelhanteao MySQL EXPLAIN, o Milvus se beneficiaria de uma ferramenta que mostrasse como uma consulta é executada e ajudasse a localizar problemas de desempenho.
Conclusão
Em resumo:
Etapa
Ferramenta / Método
Ponto-chave
Cópia de segurança
milvus-backup create
O backup a quente é suportado, mas o backup deve ser verificado cuidadosamente
Atualização
Construir um novo cluster com o Helm
Desativar o Mmap para reduzir o jitter de E/S e manter as definições de recursos iguais às do cluster antigo
Migração
milvus-backup restore
Tenha cuidado com --use_v2_restore. Na restauração de versões cruzadas, não use lógica não padrão a menos que você a entenda claramente
Implementação cinzenta
Mudança gradual de tráfego
Deslocar o tráfego por fases: 5% → 25% → 50% → 100%, e mantenha o cluster antigo pronto para a reversão
Resolução de problemas
Grafana + análise de segmento
Não olhe apenas para a CPU e a memória. Verifique também o equilíbrio do segmento e a distribuição de dados
Corrigir
Remova os dados incorretos e restaure-os novamente
Remova o sinalizador errado, restaure com a lógica padrão e o desempenho volta ao normal
Ao migrar dados, é importante considerar mais do que apenas se os dados estão presentes e são precisos. Também é necessário prestar atenção à forma como os dadossão distribuídos.
A contagem de segmentos e os tamanhos dos segmentos determinam como o Milvus distribui uniformemente o trabalho de consulta entre os nós. Quando os segmentos estão desequilibrados, alguns nós acabam fazendo a maior parte do trabalho, e todas as pesquisas pagam por isso. Atualizações de versões cruzadas trazem um risco extra aqui porque o processo de restauração pode reconstruir segmentos de forma diferente do cluster original. Sinalizadores como --use_v2_restore podem fragmentar seus dados de maneiras que a contagem de linhas por si só não mostrará.
Portanto, a abordagem mais segura na migração entre versões é manter as configurações de restauração padrão, a menos que você tenha um motivo específico para fazer o contrário. Além disso, o monitoramento deve ir além da CPU e da memória; é preciso ter uma visão do layout dos dados subjacentes, particularmente a distribuição e o equilíbrio dos segmentos, para detetar problemas mais cedo.
Uma nota da equipa Milvus
Gostaríamos de agradecer à equipa de engenharia do WPS por partilhar esta experiência com a comunidade Milvus. Relatos como este são valiosos porque capturam lições reais de produção e as tornam úteis para outros que enfrentam problemas semelhantes.
Se a sua equipa tiver uma lição técnica, uma história de resolução de problemas ou uma experiência prática que valha a pena partilhar, gostaríamos de ouvir a sua opinião. Junte-se ao nosso canal do Slack e entre em contacto connosco.
E se estiver a enfrentar os seus próprios desafios, esses mesmos canais da comunidade são um bom local para se ligar aos engenheiros da Milvus e a outros utilizadores. Também pode marcar uma sessão individual através do Milvus Office Hours para obter ajuda com cópias de segurança e restauro, actualizações entre versões e desempenho de consultas.
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
