Recomendações de ajuste de parâmetros - ApsaraDB for MongoDB: Central de Documentação do Alibaba Cloud

Em uma instância do ApsaraDB for MongoDB, você pode modificar parâmetros no console. Valores inadequados em parâmetros críticos podem causar problemas de desempenho na instância ou erros nas aplicações. Por isso, este tópico apresenta recomendações de otimização para os principais parâmetros, facilitando o processo de configuração.

Nota

Este tópico aborda apenas parâmetros de kernel e não inclui parâmetros de driver do lado do cliente, como socketTimeout.

Replica set

operationProfiling.mode

Versões principais suportadas: 3.0 ou posterior
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á quem pense incorretamente que é 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 suportadas: 3.0 ou posterior
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 que muitas consultas lentas sejam registradas, 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:
- Em aplicações sensíveis à latência, cujas consultas típicas levam cerca de 30 ms, considere reduzir o limiar para 50 a fim de facilitar a análise de flutuações transitórias de desempenho.
- Para aplicações com foco analítico, onde as consultas geralmente levam de 300 ms a 400 ms, considere aumentar o limiar para 500 ms para reduzir o ruído nos logs.

replication.oplogGlobalIdEnabled

Versões principais suportadas: 4.0 ou posterior
Reinicialização necessária: Sim
Valor padrão: false
Este parâmetro personalizado da Alibaba Cloud habilita Global IDs (GIDs) no oplog para oferecer suporte à 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. Essa alteração exige reinicialização da instância, portanto recomendamos aplicá-la fora do horário de pico.

replication.oplogSizeMB

Versões principais suportadas: 3.0 ou posterior
Reinicialização necessária: Não
Valor padrão: 10% of the instance's disk space. Por exemplo, se uma instância tiver 500 GB de espaço em disco, o valor inicial de oplogSizeMB será 51.200 (50 GB).
Função: Especifica 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 de oplog rapidamente. Um oplogSizeMB maior permite que o oplog cubra uma janela de tempo mais longa, evitando lacunas. Como prática recomendada, o tamanho do oplog deve ser suficiente para reter pelo menos uma hora de registros.

Para clusters sharded em que os shards têm tamanhos de disco inconsistentes, recomendamos usar storage.oplogMinRetentionHours para controlar a política de retenção do oplog. Esse parâmetro é suportado no MongoDB 4.4 e versões posteriores.

Nota

Esse parâmetro não é modificado em um arquivo de configuração. Em vez disso, o plano de controle da Alibaba Cloud usa o comando replsetResizeOplog para ajustar o tamanho do oplog.

setParameter.cursorTimeoutMillis

Versões principais suportadas: 3.0 ou posterior
Reinicialização necessária: Não
Valor padrão: 600000 (10 minutos)
Função: Define o tempo limite, em milissegundos, para cursores ociosos. O MongoDB limpa automaticamente qualquer cursor que permaneça ocioso 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 esse 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 suportadas: 4.2 ou posterior
Reinicialização necessária: Não
Valor padrão: 10
Função: Especifica o limiar que aciona o mecanismo de controle de fluxo. O objetivo do controle de fluxo é garantir que o ponto de commit majoritário 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 esse 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 suportadas: 4.4 ou posterior
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 source 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 essa 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 o 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 suportadas: 4.0 ou posterior
Reinicialização necessária: Não
Valor padrão: 5
Função: Especifica o tempo limite, em milissegundos, para uma transação adquirir um lock. Se uma operação na transação não conseguir obter 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 com frequência, considere aumentar esse valor. Isso pode mitigar abortamentos causados por falhas transitórias de lock, mas pode atrasar o término 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 simultâneas 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 suportadas: 3.2 ou posterior
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 essa configuração. Em circunstâncias especiais, ajuste esse parâmetro apenas sob a orientação dos engenheiros de suporte da Alibaba Cloud.

setParameter.tcmallocAggressiveMemoryDecommit

Versões principais suportadas: 4.2 ou posterior
Reinicialização necessária: Não
Valor padrão: 0 (desativa o decommit agressivo de memória do TCMalloc)
Função: O MongoDB usa 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 out-of-memory (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, fazendo com que a utilização de memória suba constantemente acima de 80%.
Recomendações: Na maioria dos casos, não recomendamos alterar essa configuração. Se encontrar problemas relacionados à memória, considere ajustar esse parâmetro fora do horário de pico.

Importante

Ativar esse parâmetro pode causar degradação de desempenho, dependendo da sua carga de trabalho. Ative-o apenas fora do horário de pico. Após a alteração, monitore sua aplicação de perto. Se observar impactos negativos, reverta a alteração do parâmetro imediatamente.

setParameter.transactionLifetimeLimitSeconds

Versões principais suportadas: 4.0 ou posterior
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 de limpeza periódica 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 esse valor (por exemplo, para 30), mas não recomendamos aumentá-lo. Transações longas não confirmadas 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 services. 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 práticas recomendadas para transações, consulte Transactions and Read/Write Concern.

storage.oplogMinRetentionHours

Versões principais suportadas: 4.4 ou posterior
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: Especifica 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 esse 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 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 defini-lo, 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 suportadas: 3.0 ou posterior
Reinicialização necessária: Sim
Valor padrão: snappy
Função: Especifica 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 custam mais sobrecarga de CPU durante a compressão e descompressão. A comparação entre algoritmos 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 suportadas: 4.4 ou posterior
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 essa 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.
- Caso sua aplicação precise ler dados de snapshots históricos com mais de 5 minutos, aumente esse 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 suportadas: 4.0 ou posterior
Reinicialização necessária: Não
Valor padrão: true
Função: Especifica 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 o 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 suportadas: 4.2 ou posterior
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 essa configuração. Se encontrar o erro acima ao executar uma consulta específica, considere aumentar o valor. No entanto, esteja ciente de que definir esse valor muito alto pode causar um erro de out-of-memory (OOM) no nó mongod.

setParameter.wiredTigerConcurrentReadTransactions/setParameter.wiredTigerConcurrentWriteTransactions

Versões principais suportadas: 3,4 ou posterior
Reinicialização necessária: Depende da versão.
- 3,4 a 6.0: Não. As alterações entram em vigor imediatamente em tempo de execução ajustando os pools de tickets correspondentes.
- 7.0 e 8.0: Depende do modo de ajuste de concorrência.
  - Se a instância usar o modo fixedConcurrentTransactions, alterações nas contagens de tickets de leitura e escrita não exigem reinicialização.
  - Por padrão, as instâncias usam o modo de ajuste dinâmico throughputProbing. Nesse modo, a modificação direta deste parâmetro falha. Para usar contagens fixas de tickets, defina storageEngineConcurrencyAdjustmentAlgorithm como fixedConcurrentTransactions na configuração de inicialização e reinicie a instância.
- 8,3 e posterior: Não. Suporta alternância em tempo de execução entre modos de ajuste de concorrência e modificação das contagens de tickets de leitura e escrita.
Valor padrão:
- 3,4 a 5.0: 128 para ambos os pools de tickets de leitura e escrita.
- 6.0 a 8.0: O valor padrão é 0, o que significa que o mecanismo de armazenamento usa seu padrão interno na inicialização, que é efetivamente 128 para tickets de leitura e escrita.
- 8,3 e posterior: 128 para ambos os pools de tickets de leitura e escrita.
Nota
A versão 7.0 e posteriores usam o modo de ajuste dinâmico throughputProbing por padrão. O sistema ajusta automaticamente as contagens de tickets de leitura e escrita com base no throughput. Nesse modo, os valores padrão descritos acima não representam as contagens reais de tickets em uso.

Nas versões principais mais recentes, os nomes dos parâmetros foram atualizados: renomeados para storageEngineConcurrentReadTransactions/storageEngineConcurrentWriteTransactions de 6.0 a 8.0, e para executionControlConcurrentReadTransactions/executionControlConcurrentWriteTransactions na 8.3. Os nomes antigos dos parâmetros permanecem compatíveis.
Função:
- wiredTigerConcurrentReadTransactions controla o número máximo de operações de leitura concorrentes que podem entrar no mecanismo de armazenamento simultaneamente, ou seja, o número de tickets de leitura.
- wiredTigerConcurrentWriteTransactions controla o número máximo de operações de escrita concorrentes que podem entrar no mecanismo de armazenamento simultaneamente, ou seja, o número de tickets de escrita.
- Operações de leitura e escrita usam pools de tickets separados. Operações que não conseguem obter um ticket são enfileiradas.
- Tickets são um mecanismo de controle de concorrência do mecanismo de armazenamento. Eles não equivalem a conexões de cliente, threads de trabalho ou memória, e não há fórmula geral para calcular uma quantidade fixa de memória consumida por ticket.
Problemas:
- Tickets de leitura esgotados por um período prolongado:
  - Consultas e operações getMore são enfileiradas, e a latência das requisições de leitura aumenta.
  - A falta de uso de pools de conexão, que causa um aumento repentino nas requisições concorrentes ativas, ou a ausência de índices apropriados que leva a varreduras completas de coleção prolongadas, pode fazer com que os tickets de leitura fiquem ocupados por longos períodos.
- Tickets de escrita esgotados por um período prolongado:
  - Requisições de escrita são enfileiradas e a latência de escrita aumenta.
  - Embora nós secundários, somente leitura e ocultos não recebam escritas regulares de negócios, eles precisam reproduzir entradas do oplog e, portanto, também consomem tickets de escrita. Quando os tickets de escrita se esgotam, o atraso de replicação pode aumentar. Consultas regulares, varreduras completas de coleção e operações getMore usam tickets de leitura e não mudam para tickets de escrita, independentemente do tempo de execução. No entanto, os recursos de CPU, I/O de disco e cache do WiredTiger que consomem podem indiretamente desacelerar a reprodução da replicação.
- Recomendações:
  - Na maioria dos casos, nenhum ajuste é necessário. Para a versão 7.0 e posteriores, recomendamos manter o modo de ajuste dinâmico padrão throughputProbing.
  - Quando ocorrer esgotamento de tickets, priorize identificar e tratar a causa raiz: 1) Certifique-se de que sua aplicação usa pools de conexão e limita adequadamente o número de requisições concorrentes ativas. 2) Adicione índices apropriados para consultas lentas a fim de evitar varreduras completas de coleção desnecessárias. 3) Verifique se CPU, I/O de disco, cache do WiredTiger, contenção de locks ou atraso de replicação atingiram um gargalo.
  - **Não aumente este parâmetro apenas porque available é 0. Se a CPU, disco ou cache subjacentes já estiverem saturados, aumentar a contagem de tickets permite que mais operações entrem no mecanismo de armazenamento simultaneamente, o que pode piorar o enfileiramento de I/O, evicção de cache, contenção de locks e picos de latência.**
  - Não existem valores recomendados que possam ser aplicados diretamente com base nas especificações da instância. Somente após confirmar que o gargalo é realmente causado pelos limites de concorrência de tickets e que os recursos subjacentes ainda têm capacidade, faça pequenos ajustes incrementais fora do horário de pico e observe durante um ciclo completo de negócios.
  - Se o objetivo for limitar a concorrência e proteger o disco ou cache, também é possível diminuir os valores no modo de concorrência fixa, mas isso reduz o throughput de pico.
  - Antes e depois dos ajustes de parâmetros, monitore continuamente métricas como latência de leitura e escrita, tempo de enfileiramento, atraso de replicação, utilização de disco e evicção de cache do WiredTiger.
  Importante
  Este parâmetro não pode ser ajustado pelo console. Se precisar ajustá-lo, envie um ticket para avaliação do suporte técnico.
  
  As versões 7.0 e 8.0 usam o modo de ajuste dinâmico por padrão. Alternar para o modo de concorrência fixa exige reinicialização. Após a alternância, o sistema não ajusta mais automaticamente as contagens de tickets com base no throughput, o que pode afetar o desempenho e a estabilidade da instância. Não alterne os modos apenas para aliviar temporariamente o enfileiramento.

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

Replica set

operationProfiling.mode

operationProfiling.slowOpThresholdMs

replication.oplogGlobalIdEnabled

replication.oplogSizeMB

setParameter.cursorTimeoutMillis

setParameter.flowControlTargetLagSeconds

setParameter.oplogFetcherUsesExhaust

setParameter.maxTransactionLockRequestTimeoutMillis

setParameter.replWriterThreadCount

setParameter.tcmallocAggressiveMemoryDecommit

setParameter.transactionLifetimeLimitSeconds

storage.oplogMinRetentionHours

storage.wiredTiger.collectionConfig.blockCompressor

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

rsconf.chainingAllowed

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

setParameter.wiredTigerConcurrentReadTransactions/setParameter.wiredTigerConcurrentWriteTransactions

Sharded cluster (shard)

setParameter.migrateCloneInsertionBatchSize

setParameter.rangeDeleterBatchDelayMS

setParameter.rangeDeleterBatchSize

setParameter.receiveChunkWaitForRangeDeleterTimeoutMS

setParameter.minSnapshotHistoryWindowInSeconds/setParameter.maxTargetSnapshotHistoryWindowInSeconds

rsconf.chainingAllowed

setParameter.periodicNoopIntervalSecs

setParameter.wiredTigerConcurrentReadTransactions/setParameter.wiredTigerConcurrentWriteTransactions

setParameter.internalQueryMaxPushBytes/setParameter.internalQueryMaxAddToSetBytes

Sharded cluster (mongos)

operationProfiling.slowOpThresholdMs

setParameter.ShardingTaskExecutorPoolMaxConnecting

setParameter.ShardingTaskExecutorPoolMaxSize

setParameter.ShardingTaskExecutorPoolMinSize

setParameter.cursorTimeoutMillis