O processo do MongoDB Search (mongot) executa queries em um pool de execução fixo. Quando as queries chegam mais rápido do que o processo pode executá-las, o Atlas mantém o excesso de queries em uma fila de controle de entrada em vez de executá-las todas de uma vez. A redução de carga de pesquisa rege essa fila. Ele protege o processo de pesquisa do esgotamento da memória e do colapso de latência que ocorre quando um processo aceita mais trabalho simultâneo do que pode concluir.
A redução de carga de pesquisa se aplica às queries $search e $vectorSearch. Ele está disponível em clusters que executam o MongoDB 8.0, 8.3 e 9.0 ou posterior, e o Atlas o ativa por padrão em clusters que executam o MongoDB 9.0 ou mais tarde.
Quando o processo de pesquisa atinge sua capacidade de execução, o Atlas coloca as consultas recebidas na fila. As queries em fila são executadas quando a capacidade é liberada, portanto são concluídas com sucesso, mas com latência mais alta do que o normal. A latência permanece elevada até que a taxa de chegada caia abaixo da taxa na qual o processo pode permitir trabalho.
A qualquer momento, uma query está em execução no pool de execução, aguardando na fila de controle de entrada ou rejeitada. Somente uma fila cheia causa rejeção.
A redução de carga de pesquisa não altera o número de queries que o processo de pesquisa executa simultaneamente. Muda apenas se a fila do controle de entrada tem um limite de capacidade:
Com uma fila ilimitada, o Atlas coloca cada query em excesso na fila. As queries sempre são executadas, mas a sobrecarga sustentada produz latência crescente.
Com uma fila limitada, o Atlas ainda enfileira queries em excesso, mas somente até um limite de capacidade. Quando a fila está cheia, o Atlas rejeita outras queries imediatamente, em vez de adicionar latência para cada cliente.
O Atlas define internamente o tamanho do pool de execução e a capacidade da fila delimitada e pode alterar esses limites a qualquer momento.
No momento em que o Atlas começa a rejeitar as queries, a sobrecarga já aumentou a latência para as queries que o Atlas aceita. A rejeitação elimina o excesso de carga, o que impede que a latência se degrade ainda mais. Ele também mantém o processo de pesquisa responsivo, em vez de permitir que ele falhe totalmente.
Erros de query rejeitados
Quando o Atlas rejeita uma query porque a fila de controle de entrada está cheia, a query falha com o seguinte erro:
Campo | Valor |
|---|---|
Código de erro |
|
Nome de código |
|
Etiqueta de erro |
|
Todas as versões que oferecem suporte à redução de carga de pesquisa retornam esse mesmo erro, para que seu aplicação possa confiar em um único contrato de erro.
Importante
As queries rejeitadas não podem ser repetidas
O erro 489 não carrega o rótulo RetryableError. Nem os drivers do MongoDB nem o mongod tentam novamente uma query rejeitada automaticamente. Seu aplicação deve decidir como responder.
Uma recusa significa que o processo de busca já está saturado. A nova tentativa adiciona imediatamente carga a um processo que não pode absorvê-la, o que estende a sobrecarga e aumenta o número de rejeições. Para responder a um erro 489, aplique as seguintes práticas:
Pegue o rótulo
SystemOverloadedErrorem vez de corresponder ao texto da mensagem de erro.Aguarde antes de enviar a query novamente. Use o backoff exponencial com jitter para que os clientes simultâneos não tentem novamente em sincronia entre si.
Limite o número de tentativas. Exponha um resultado degradado ou um erro ao usuário final em vez de tentar novamente indefinidamente.
Reduza a taxa na qual seu aplicação envia consultas de pesquisa enquanto as rejeições persistem. Reduzir a simultaneidade do cliente reduz a sobrecarga.
Trate as rejeições sustentadas como um sinal de capacidade em vez de uma falha transitória e dimensione ou otimize seu volume de trabalho de pesquisa.
Monitore e reduza a sobrecarga de pesquisa
O Atlas relata o enfileiramento antes que resulte em rejeições, o que lhe dá tempo para agir. Use os seguintes sinais:
A métrica Search Process Throttling informa a taxa na qual o processo de pesquisa sinalizou que excedeu seu limite de fila. Um valor diferente de zero sustentado significa que o trabalho chega mais rápido do que o processo pode administrá-lo. Para visualizar essa métrica, consulte Revisar métricas de pesquisa do MongoDB .
O alerta MongoDB Search: Search Process is Overloaded é acionado quando a condição persiste por 5 minutos. Para resolver esse alerta, consulte Corrigir problemas de pesquisa do MongoDB .
Para reduzir a carga que chega ao processo de pesquisa, realize as seguintes ações:
Implemente nós de pesquisa para isolar o volume de trabalho de pesquisa ou atualize para uma camada de nós de pesquisa com mais vCPUs.
Distribua as queries ao longo do tempo em vez de enviá-las em intermitências.
Otimize suas queries. Adicione filtros, reduza os principais curingas e cláusulas profundamente aninhadas e retorne apenas os campos necessários.
Configurar divisão de carga de query
Configure o descarte de carga de pesquisa por cluster. A configuração aceita os seguintes estados:
Estado | API Value | Descrição |
|---|---|---|
Atlas gerenciado | Sem substituição | O Atlas seleciona o estado com base na versão MongoDB que seu cluster executa. O Atlas resolve esse estado para Off no MongoDB 8.0 e 8.3 e para On no MongoDB 9.0 ou posterior. |
Ligado |
| A fila de controle de entrada é limitada. O Atlas enfileira queries em excesso até um limite de capacidade e, em seguida, rejeita outras queries com um erro |
Desligado |
| A fila de controle de entrada não tem limite. O Atlas coloca cada query em excesso e nunca rejeita uma query. |
Use a UI do Atlas ou a API de administração do Atlas para alterar o estado.