ApsaraDB for MongoDB:Recomendações de ajuste de parâmetros

operationProfiling.mode

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Sim

• Valor padrão: off

• Função: Define o nível de profiling do query profiler.

• Problemas:

  • Se este parâmetro estiver definido como all ou slowOp, o grande volume de logs de consultas lentas gerados pode degradar o desempenho da instância e dificultar a análise.

  • Alguns usuários podem se confundir ao encontrar uma coleção system.profile no banco de dados caso esqueçam de desativar o query profiler.

  • Há usuários que acreditam incorretamente ser obrigatório definir este parâmetro como slowOp para gerar logs de consultas lentas.

• Recomendações:

  Mantenha o valor padrão. O log de consultas lentas fornece informações analíticas semelhantes sem a sobrecarga de desempenho do query profiler. Ative esse recurso somente quando necessário e desative-o logo após concluir a análise. Para mais informações sobre o Database Profiler, consulte a documentação oficial do MongoDB.

operationProfiling.slowOpThresholdMs

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 100

• Função: Define o limiar, em milissegundos, para que uma consulta seja considerada lenta.

• Problemas:

  • Um valor muito baixo gera um grande volume de logs de consultas lentas e logs de auditoria, criando ruído que dificulta a análise.

  • Um valor muito alto impede o registro de muitas consultas lentas, o que atrapalha o processo de análise.

• Recomendações: Ajuste o limiar conforme sua carga de trabalho. Recomendamos definir um valor ligeiramente superior à latência média das suas consultas críticas. Por exemplo:

  • Para aplicações sensíveis à latência, cujas consultas típicas levam cerca de 30 ms, considere reduzir o limiar para 50, facilitando a análise de flutuações transitórias de desempenho.

  • Para aplicações com foco em análises, cujas consultas geralmente levam de 300 ms a 400 ms, considere aumentar o limiar para 500 ms, reduzindo o ruído nos logs.

replication.oplogGlobalIdEnabled

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Sim

• Valor padrão: false

• Este parâmetro personalizado da Alibaba Cloud habilita Global IDs (GIDs) no oplog para suportar sincronização bidirecional com ferramentas como Data Transmission Service (DTS) ou mongoShake. Os GIDs evitam problemas de replicação circular nessas configurações.

• Recomendações: Ative este parâmetro apenas quando a sincronização bidirecional for necessária. Como essa alteração exige reinicialização da instância, recomendamos aplicá-la fora do horário de pico.

replication.oplogSizeMB

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 10% of the instance's disk space. Por exemplo, se uma instância possui 500 GB de espaço em disco, o valor inicial de oplogSizeMB será 51.200 (50 GB).

• Função: Especifique o tamanho lógico máximo da coleção oplog, que armazena logs de replicação.

• Problemas: Um valor muito baixo pode fazer com que os nós secundários fiquem atrasados e entrem no estado RECOVERING. Também pode criar lacunas nos backups de log, impedindo a recuperação point-in-time.

• Recomendações: Mantenha o valor padrão. Não o reduza. Aumente-o apenas quando necessário. Considere aumentar o valor para cargas de trabalho com baixo volume de dados, mas alta taxa de atualizações, que geram entradas no oplog rapidamente. Um oplogSizeMB maior permite que o oplog cubra uma janela de tempo mais longa, evitando lacunas. Como melhor prática, o tamanho do oplog deve ser suficiente para reter pelo menos uma hora de registros.

setParameter.cursorTimeoutMillis

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 600000 (10 minutos)

• Função: Define o tempo limite, em milissegundos, para um cursor ocioso. O MongoDB limpa automaticamente qualquer cursor que permaneça inativo além desse limiar.

• Problemas: Se você tentar acessar um cursor que expirou e foi limpo, o cliente receberá um erro no seguinte formato:

  Message: "cursor id xxxxxxx not found"
  ErrorCode: CursorNotFound(43)

• Recomendações: Não recomendamos aumentar este valor. Para reduzir a sobrecarga de recursos de cursores ociosos, diminua o valor (por exemplo, para 300000). Em todos os cenários, sua aplicação deve evitar a criação de cursores ociosos de longa duração.

setParameter.flowControlTargetLagSeconds

• Versões principais compatíveis: 4,2 ou superior

• Reinicialização necessária: Não

• Valor padrão: 10

• Função: Define o limiar que aciona o mecanismo de controle de fluxo. O objetivo do controle de fluxo é garantir que o ponto de commit da maioria não fique muito atrasado.

• Problemas: A latência das requisições aumenta significativamente e logs de consultas lentas semelhantes ao exemplo abaixo aparecem. Um valor de durationMillis quase igual a flowControl.timeAcquiringMicros indica que o mecanismo de controle de fluxo desacelerou a requisição.

  {
    "t": {
      "$date": "2024-04-25T13:28:45.840+08:00"
    },
    "s": "I",
    "c": "WRITE",
    "id": 51803,
    "ctx": "conn199253",
    "msg": "Slow query",
    "attr": {
      "type": "update",
      "ns": "xxx.xxxxx",
      "command": ...,
      "planSummary": "IDHACK",
      "totalOplogSlotDurationMicros": 61,
      "keysExamined": 1,
      "docsExamined": 1,
      "nMatched": 1,
      "nModified": 1,
      "nUpserted": 0,
      "keysInserted": 0,
      "keysDeleted": 0,
      "numYields": 0,
      "locks": ...,
      "flowControl": {
        "acquireCount": 1,
        "acquireWaitCount": 1,
        "timeAcquiringMicros": 959000
      },
      "readConcern": {
        "level": "local",
        "provenance": "implicitDefault"
      },
      "storage": {},
      "cpuNanos": 258845,
      "remote": "172.16.6.38:52368",
      "durationMillis": 959
    }
  }
  

• Recomendações: Aumente este valor para tornar o mecanismo de controle de fluxo menos sensível. Se as requisições continuarem sendo limitadas frequentemente após o aumento, isso indica um possível gargalo de desempenho na replicação. Nesse caso, realize uma análise mais detalhada e tome outras medidas, como atualizar a configuração da instância ou definir o write concern como majority.

setParameter.oplogFetcherUsesExhaust

• Versões principais compatíveis: 4,4 ou superior

• Reinicialização necessária: Sim

• Valor padrão: true

• Função: Define se a replicação por streaming está ativada. Se esse recurso for desativado, a replicação volta ao método baseado em pull das versões anteriores. Nesse método, um nó secundário solicita um lote de entradas do oplog de sua fonte de sincronização, exigindo uma ida e volta na rede para cada lote.

• Problemas: Em alguns cenários, o mecanismo de replicação por streaming pode introduzir sobrecarga adicional de desempenho e largura de banda de rede.

• Recomendação: Não altere esta configuração. A replicação por streaming reduz a latência de replicação em ambientes de alta carga e redes com alta latência. Ela também diminui o risco de perda de escrita se o nó primário cair inesperadamente quando writeConcern estiver definido como {w:1}, além de reduzir a latência de escrita para outras configurações de writeConcern que dependem da replicação primário-secundário, como {w:majority} ou {w:>1}.

setParameter.maxTransactionLockRequestTimeoutMillis

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 5

• Função: Define o tempo limite, em milissegundos, para uma transação adquirir um lock. Se uma operação na transação não conseguir adquirir o lock necessário dentro desse período, a transação é abortada automaticamente.

• Problemas: A seguinte mensagem de erro de tempo limite de lock aparece nos logs ou é retornada ao cliente. Drivers modernos podem tentar novamente automaticamente em caso de TransientTransactionError, então o erro pode ser visível apenas nos logs e não percebido pelo cliente.

  Message: "Unable to acquire lock '{8442595743001781021: Database, 1525066715360699165}' within a max lock request timeout of '5ms' milliseconds."
  ErrorCode: LockTimeout(24)

• Recomendações: Se seu cliente encontrar esse erro frequentemente, considere aumentar este valor. Isso pode mitigar abortamentos causados por falhas transitórias de lock, mas pode atrasar o encerramento de transações envolvidas em deadlocks. Se o problema persistir, otimize a lógica da aplicação em vez de aumentar ainda mais o valor. Por exemplo, evite modificações concorrentes no mesmo documento e revise operações de tarefas longas (como DDL ou consultas não otimizadas) que possam manter locks por um período prolongado.

setParameter.replWriterThreadCount

• Versões principais compatíveis: 3,2 ou superior

• Reinicialização necessária: Sim

• Valor padrão: 16

• Função: Define o número máximo de threads para replicação paralela. O número máximo efetivo de threads é o dobro do número de núcleos de CPU da instância.

• Problemas: Em casos extremos, o atraso de replicação nos nós secundários aumenta continuamente.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Em circunstâncias especiais, ajuste este parâmetro apenas sob a orientação dos engenheiros de suporte da Alibaba Cloud.

setParameter.tcmallocAggressiveMemoryDecommit

• Versões principais compatíveis: 4,2 ou superior

• Reinicialização necessária: Não

• Valor padrão: 0 (desativa o decommit agressivo de memória do TCMalloc)

• Função: O MongoDB utiliza o alocador de memória TCMalloc. Este parâmetro controla a política de decommit agressivo do TCMalloc, que mescla proativamente blocos de memória livre adjacentes e os devolve ao sistema operacional.

• Problemas:

  • Um nó mongod apresenta erro de falta de memória (OOM) porque a memória não pode ser recuperada rápido o suficiente devido ao alto consumo de memória pelas consultas.

  • À medida que a instância executa, a fragmentação da memória heap aumenta, levando a uma utilização de memória que sobe constantemente acima de 80%.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se encontrar problemas relacionados à memória, considere ajustar este parâmetro fora do horário de pico.

setParameter.transactionLifetimeLimitSeconds

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 60

• Função: Define o tempo de vida de uma transação, em segundos. Se o tempo total de execução de uma transação exceder esse limite, ela é marcada como expirada e abortada por uma thread periódica de limpeza em segundo plano.

• Problemas: O cliente recebe um erro no seguinte formato:

  Message: "Aborting transaction with txnNumber xxx on session with lsid xxxxxxxxxx because it has been running for longer than 'transactionLifetimeLimitSeconds'"

• Recomendação: Diminua este valor (por exemplo, para 30), mas não recomendamos aumentá-lo. Transações não confirmadas de longa duração podem exercer pressão significativa sobre o cache do mecanismo de armazenamento WiredTiger. Um cache sobrecarregado frequentemente leva a mais problemas, como congelamentos do banco de dados, aumentos abruptos na latência das requisições e utilização máxima da CPU, o que pode degradar seus serviços. Sua aplicação deve evitar transações longas sempre que possível. Para resolver problemas de tempo limite, divida as transações em partes menores para que possam ser concluídas dentro do limite de tempo configurado. Garanta também que suas consultas estejam otimizadas e tenham cobertura adequada de índices para acesso rápido aos dados dentro das transações.

Para mais informações sobre melhores práticas para transações, consulte Transações e Read/Write Concern.

storage.oplogMinRetentionHours

• Versões principais compatíveis: 4,4 ou superior

• Reinicialização necessária: Não

• Valor padrão: 0 (Um valor de 0 indica que este parâmetro está desativado e o tamanho do oplog é controlado inteiramente pelo parâmetro replication.oplogSizeMB.)

• Função: Define o período mínimo de retenção, em horas, para o oplog.

• Problemas:

  • Um valor muito alto pode fazer com que o oplog consuma espaço excessivo em disco.

  • Alguns usuários podem esquecer que definiram este parâmetro e ficar confusos com as flutuações no uso de espaço em disco da instância.

• Recomendações: Para cargas de trabalho relativamente estáveis, mantenha o valor padrão. Para cargas de trabalho que podem apresentar flutuações significativas nas operações de escrita, recomendamos definir este parâmetro como um número de ponto flutuante maior que 1,0. Ao configurar este parâmetro, avalie também o potencial consumo de espaço em disco para evitar outros problemas causados por disco cheio.

storage.wiredTiger.collectionConfig.blockCompressor

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Sim

• Valor padrão: snappy

• Função: Define o algoritmo de compressão de armazenamento para dados de coleções. Esta configuração aplica-se apenas a tabelas recém-criadas e não afeta tabelas existentes. Atualmente, os algoritmos suportados são: sem compressão, snappy, zlib e zstd. O algoritmo zstd é suportado apenas nas versões 4,2 e posteriores.

• Recomendações: Modifique conforme necessário. Diferentes algoritmos de compressão oferecem desempenhos distintos. Alguns proporcionam taxas de compressão mais altas, mas às custas de maior sobrecarga de CPU durante a compressão e descompressão. A comparação entre algoritmos de compressão deve basear-se em seus próprios testes. Se a instância for usada principalmente para armazenar dados frios, considere alterar este parâmetro para zstd a fim de obter uma taxa de compressão maior.

  Nota

  Se quiser usar algoritmos de compressão diferentes para coleções distintas, use o comando explícito createCollection com as opções relevantes. Para mais informações, consulte a documentação oficial do MongoDB.

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• Versões principais compatíveis: 4,4 ou superior

• Reinicialização necessária: Não

• Valor padrão: 300 (5 minutos)

• Função: Define o tamanho da janela, em segundos, durante a qual o mecanismo de armazenamento WiredTiger retém o histórico de snapshots. Um valor de 0 desativa a janela de histórico de snapshots. Este parâmetro é usado principalmente para suportar leituras em um atClusterTime específico.

• Problemas: Este parâmetro pode aumentar a pressão sobre o cache do WiredTiger, especialmente em cenários com atualizações frequentes no mesmo documento.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração.

  • Se sua aplicação não usar o recurso read atClusterTime, defina este parâmetro como 0 para obter uma pequena melhoria de desempenho.

  • Se sua aplicação precisar ler dados de snapshots históricos com mais de 5 minutos, aumente este valor. No entanto, esteja ciente de que isso levará a consumo adicional de memória e sobrecarga de desempenho.

  Nota

  Se o valor deste parâmetro for baixo e você especificar um tempo muito antigo ao ler um snapshot histórico, receberá um erro SnapshotTooOld.

rsconf.chainingAllowed

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: true

• Função: Define se a replicação em cadeia é permitida em um replica set.

• Problemas:

  • Desativar a replicação em cadeia pode aumentar a carga no nó primário, como utilização de CPU e tráfego de rede.

  • Ativar a replicação em cadeia pode aumentar o atraso de replicação nos nós secundários.

• Recomendações:

  • Para replica sets com quatro nós ou menos: Ative ou desative a replicação em cadeia conforme suas necessidades.

  • Quando o número de nós for grande (5 ou mais), faça uma avaliação cuidadosa entre a carga do nó primário e o desempenho da instância apenas quando writeConcern estiver configurado como {w:majority}. Desativar a replicação em cadeia ajuda a melhorar o desempenho de escrita, mas a carga correspondente no nó primário também aumenta significativamente.

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• Versões principais compatíveis: 4,2 ou superior

• Reinicialização necessária: Não

• Valor padrão: 104.857.600 B (100 MB)

• Função: Limita o uso máximo de memória para os operadores $push e $addToSet.

• Sintoma: Uma instrução SQL específica contendo $push ou $addToSet falha ao executar e retorna a seguinte mensagem de erro.

  "errMsg": "$push used too much memory and cannot spill to disk. Memory limit: 104857600... 

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se encontrar o erro acima ao executar uma consulta específica, considere aumentar o valor. No entanto, esteja ciente de que definir este valor muito alto pode causar um erro de falta de memória (OOM) no nó mongod.

setParameter.migrateCloneInsertionBatchSize

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 0 (limitado pelo limite de tamanho de documento de 16 MB)

• Função: Define o número máximo de documentos em um único lote durante a etapa de clonagem da migração de chunks.

• Problemas: A migração de chunks pode causar flutuações de desempenho no shard.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se sua instância de sharded cluster apresentar flutuações de desempenho durante o balanceamento devido à migração de chunks, considere definir este parâmetro com um tamanho de lote fixo.

setParameter.rangeDeleterBatchDelayMS

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 20

• Função: Define o intervalo para exclusões em lote durante a etapa de limpeza da migração de chunks. Esta configuração também afeta o comando cleanupOrphaned para limpeza de documentos órfãos. A unidade é milissegundos.

• Problemas:

  • Em alguns cenários, a exclusão assíncrona de documentos após a migração de chunks pode causar um pico na utilização da CPU.

  • Um valor muito alto pode fazer com que documentos se tornem órfãos por não serem excluídos a tempo. Também pode causar tempos limite se houver muitos documentos para excluir, resultando no seguinte log de erro:

    Message: "OperationFailed: Data transfer error: ExceededTimeLimit: Failed to delete orphaned <db>.<collection> range [xxxxxx,xxxxx] :: caused by :: operation exceeded time limit"

• Recomendação: Geralmente, nenhum ajuste é necessário. Se a utilização da CPU de uma instância de sharded cluster tiver picos durante o balanceamento devido à exclusão assíncrona de documentos, aumente este parâmetro, por exemplo, para 200.

setParameter.rangeDeleterBatchSize

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 0 (escolhe automaticamente um tamanho de lote razoável, tipicamente 128)

• Função: Define o número máximo de documentos em um único lote para exclusão assíncrona durante a etapa de limpeza da migração de chunks.

• Problemas: Em alguns cenários, a exclusão assíncrona de documentos após a migração de chunks pode causar um pico na utilização da CPU.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se a utilização da CPU da sua instância de sharded cluster tiver picos durante o balanceamento devido à exclusão assíncrona de documentos, considere definir este parâmetro com um tamanho de lote fixo.

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

• Versões principais compatíveis: 4,4 ou superior

• Reinicialização necessária: Não

• Valor padrão: 10000 (10 segundos)

• Função: Define o tempo limite, em milissegundos, para aguardar a exclusão de documentos órfãos antes de uma migração de chunk.

• Problemas: Enquanto o balancer está em execução, você pode ver um log de erro de tempo limite semelhante ao seguinte:

  ExceededTimeLimit: Failed to delete orphaned <db.collection> range [{ <shard_key>: MinKey }, { <shard_key>: -9186000910690368367 }) :: caused by :: operation exceeded time limit

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se encontrar o erro acima, aumente este valor para permitir que a operação moveChunk aguarde mais tempo pela conclusão da exclusão de documentos órfãos, evitando assim tais erros de tempo limite.

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

• Versões principais compatíveis: 4,4 ou superior

• Reinicialização necessária: Não

• Valor padrão: 300 (5 minutos)

• Função: Define o tamanho da janela, em segundos, durante a qual o mecanismo de armazenamento WiredTiger retém o histórico de snapshots. Um valor de 0 desativa a janela de histórico de snapshots. Este parâmetro é usado principalmente para suportar leituras em um atClusterTime específico.

• Problemas: Este parâmetro pode aumentar a pressão sobre o cache do WiredTiger, especialmente em cenários com atualizações frequentes no mesmo documento.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração.

  • Se sua aplicação não usar o recurso read atClusterTime, defina este parâmetro como 0 para obter uma pequena melhoria de desempenho.

  • Se sua aplicação precisar ler dados de snapshots históricos com mais de 5 minutos, aumente este valor. No entanto, esteja ciente de que isso levará a consumo adicional de memória e sobrecarga de desempenho.

  Nota

  Se o valor deste parâmetro for baixo e você especificar um tempo muito antigo ao ler um snapshot histórico, receberá um erro SnapshotTooOld.

rsconf.chainingAllowed

• Versões principais compatíveis: 4,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: true

• Função: Define se a replicação em cadeia é permitida em um shard.

• Problemas:

  • Desativar a replicação em cadeia pode aumentar a carga no nó primário, como utilização de CPU e tráfego de rede.

  • Ativar a replicação em cadeia pode aumentar o atraso de replicação nos nós secundários.

• Recomendações:

  • Para shards com quatro nós ou menos: Ative ou desative a replicação em cadeia conforme suas necessidades.

  • Se você tiver um grande número de nós (5 ou mais) e writeConcern estiver configurado como {w:majority}, faça uma avaliação cuidadosa entre a carga no nó primário e o desempenho da instância. Desativar a replicação em cadeia melhora o desempenho de escrita, mas também aumenta significativamente a carga no nó primário.

setParameter.periodicNoopIntervalSecs

• Versões principais compatíveis: 4,2 ou superior

• Reinicialização necessária: Sim

• Valor padrão: 10

• Função: O intervalo, em segundos, para escritas no-op (noop).

• Problemas: Ao usar Change Streams, shards com baixa atividade de escrita podem se tornar um gargalo para o mongos ao agregar alterações. Isso pode levar a um atraso no Change Stream de cerca de 10 segundos.

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se experiencing o atraso descrito acima ao usar Change Streams, considere reduzir este parâmetro para 1. Isso aumenta a frequência de escritas no-op e evita atrasos no consumo do Change Stream causados por baixa atividade de escrita em um único shard.

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

• Versões principais compatíveis: 4,2 ou superior

• Reinicialização necessária: Não

• Valor padrão: 104.857.600 B (100 MB)

• Função: Limita o uso máximo de memória para os operadores $push e $addToSet.

• Sintoma: Uma instrução SQL específica contendo $push ou $addToSet falha ao executar e retorna a seguinte mensagem de erro.

  "errMsg": "$push used too much memory and cannot spill to disk. Memory limit: 104857600... 

• Recomendações: Na maioria dos casos, não recomendamos alterar esta configuração. Se encontrar o erro acima ao executar uma consulta específica, considere aumentar o valor. No entanto, esteja ciente de que definir este valor muito alto pode causar um erro de falta de memória (OOM) no nó mongod.

operationProfiling.slowOpThresholdMs

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 100

• Função: Define o limiar, em milissegundos, para que uma consulta seja considerada lenta.

• Problemas:

  • Um valor muito baixo gera um grande volume de logs de consultas lentas e logs de auditoria, criando ruído que dificulta a análise.

  • Um valor muito alto impede o registro de muitas consultas lentas, o que atrapalha o processo de análise.

• Recomendações: Ajuste o limiar conforme sua carga de trabalho. Recomendamos definir um valor ligeiramente superior à latência média das suas consultas críticas. Por exemplo:

  • Para aplicações sensíveis à latência, cujas consultas típicas levam cerca de 30 ms, considere reduzir o limiar para 50, facilitando a análise de flutuações transitórias de desempenho.

  • Para aplicações com foco em análises, cujas consultas geralmente levam de 300 ms a 400 ms, considere aumentar o limiar para 500 ms, reduzindo o ruído nos logs.

setParameter.ShardingTaskExecutorPoolMaxConnecting

• Versões principais compatíveis: 3,6 ou superior

• Reinicialização necessária:

  • Para versões 3,6 e 4,0: Sim

  • Para versões 4,2 e posteriores: Não

• Valor padrão: 2

• Função: Define o número máximo de conexões simultâneas que o pool de conexões TaskExecutor em um nó mongos pode estabelecer durante a inicialização. Controla a taxa em que as conexões são criadas do mongos para os nós de shard.

• Problemas: Se este valor for definido muito alto, a criação de muitas conexões de uma só vez pode causar um pico na utilização da CPU no nó mongos.

• Recomendações: Não recomendamos alterar esta configuração.

setParameter.ShardingTaskExecutorPoolMaxSize

• Versões principais compatíveis: 3,6 ou superior

• Reinicialização necessária:

  • Para versões 3,6 e 4,0: Sim

  • Para versões 4,2 e posteriores: Não

• Valor padrão: 2^64-1 (valor máximo para um inteiro de 64 bits)

• Função: Define o número máximo de conexões em cada pool de conexões TaskExecutor em um nó mongos.

• Recomendações: Nenhum ajuste é necessário. Defina este parâmetro para limitar o tamanho do pool de conexões de um mongos para os shards, mas não recomendamos definir um valor muito baixo. Um valor muito pequeno pode fazer com que as requisições no mongos sejam bloqueadas quando o pool de conexões se esgotar.

setParameter.ShardingTaskExecutorPoolMinSize

• Versões principais compatíveis: 3,6 ou superior

• Reinicialização necessária:

  • Para versões 3,6 e 4,0: Sim

  • Para versões 4,2 e posteriores: Não

• Valor padrão: 1

• Função: Define o número mínimo de conexões em cada pool de conexões TaskExecutor em um nó mongos.

• Problemas: Uma explosão repentina de requisições pode forçar o pool de conexões TaskExecutor em um nó mongos a criar muitas novas conexões de uma só vez, o que pode causar picos na utilização da CPU e outros problemas.

• Recomendação: Defina um valor razoável no intervalo de [10,50]. O valor específico deve depender da topologia da instância de shard (o número de shards e o número de nós em cada shard). Observe que o mongos incorre em uma pequena sobrecarga de recursos para manter essas conexões ociosas com os shards.

setParameter.cursorTimeoutMillis

• Versões principais compatíveis: 3,0 ou superior

• Reinicialização necessária: Não

• Valor padrão: 600000 (10 minutos)

• Função: Define o limiar de expiração para um cursor ocioso, em milissegundos. O MongoDB limpa automaticamente qualquer cursor que permaneça inativo além desse limiar.

• Problemas: Se você tentar acessar um cursor que expirou e foi limpo, o cliente receberá um erro no seguinte formato:

  Message: "cursor id xxxxxxx not found"
  ErrorCode: CursorNotFound(43)

• Recomendações: Não recomendamos aumentar este valor. Para reduzir a sobrecarga de recursos de cursores ociosos, diminua o valor (por exemplo, para 300000). Em todos os cenários, sua aplicação deve evitar a criação de cursores ociosos de longa duração.