As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solução de problemas do Amazon DocumentDB
As seções a seguir fornecem informações sobre como solucionar problemas que você pode encontrar ao usar o Amazon DocumentDB (compatível com MongoDB).
**Topics**
+ [Problemas de conexão](troubleshooting.connecting.md)
+ [Índices](troubleshooting.index-creation.md)
+ [Desempenho e utilização de recursos](user_diagnostics.md)
+ [Coleta de resíduos](garbage-collection.md)
# Solução de problemas de conexão
Está tendo problemas para se conectar? Aqui estão alguns cenários comuns e como resolvê-los.
**Tópicos**
+ [Não é possível conectar-se a um endpoint do Amazon DocumentDB](#troubleshooting-connecting)
+ [Testar uma conexão com uma instância do Amazon DocumentDB](#troubleshooting.testing-connection)
+ [Conectar a um endpoint inválido](#troubleshooting.invalid-endpoint)
+ [A configuração do driver afeta o número de conexões](#troubleshooting.driver.config)
## Não é possível conectar-se a um endpoint do Amazon DocumentDB
Quando você tentar se conectar ao Amazon DocumentDB, a mensagem de erro a seguir é uma das mais comuns que você pode receber.
```
connecting to: mongodb://docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-
1.docdb.amazonaws.com:27017/
2018-11-14T14:33:46.451-0800 W NETWORK [thread1] Failed to connect to
172.31.91.193:27017 after 5000ms milliseconds, giving up.
2018-11-14T14:33:46.452-0800 E QUERY [thread1] Error: couldn't connect to server
docdb-2018-11-08-21-47-27.cluster-ccuszbx3pn5e.us-east-1.docdb.amazonaws.com:27017,
connection attempt failed :
connect@src/mongo/shell/mongo.js:237:13
@(connect):1:6
exception: connect failed
```
O que essa mensagem de erro normalmente significa é que seu cliente (o shell do mongo, nesse exemplo) não pode acessar o endpoint do Amazon DocumentDB. Este pode ser o caso por vários motivos:
**Topics**
+ [Conectar de endpoints públicos](#troubleshooting.cannot-connect.public-endpoints)
+ [Conexões inter-regionais](#troubleshooting.cannot-connect.different-regions)
+ [Conectando-se de diferentes Amazon VPCs](#troubleshooting.cannot-connect.different-vpcs)
+ [O grupo de segurança bloqueia as conexões de entrada.](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Problema de preferência de leitura do driver Java Mongo](#troubleshooting-cannot-connect-java-mongo-issue)
### Conectar de endpoints públicos
**Você está tentando se conectar a um cluster do Amazon DocumentDB diretamente do seu laptop ou máquina de desenvolvimento local.**
Tentar se conectar a um cluster do Amazon DocumentDB diretamente de um endpoint público, como seu laptop ou máquina de desenvolvimento local, falhará. O Amazon DocumentDB é apenas uma nuvem privada virtual (VPC) e não oferece suporte a endpoints públicos no momento. Assim, você não poderá se conectar diretamente ao seu cluster do Amazon DocumentDB do seu laptop nem do ambiente de desenvolvimento local fora da sua VPC.
Para se conectar a um cluster do Amazon DocumentDB de fora de uma Amazon VPC, você pode usar o túnel SSH. Para obter mais informações, consulte [Conectar-se a um cluster do Amazon DocumentDB de fora de uma Amazon VPC](connect-from-outside-a-vpc.md). Além disso, se o ambiente de desenvolvimento estiver em outra Amazon VPC, você também poderá usar o VPC Peering e conectar-se ao seu cluster do Amazon DocumentDB de outra na mesma região ou em uma região diferente.
### Conexões inter-regionais
**Você está tentando se conectar a um cluster do Amazon DocumentDB em outra região.**
Se você tentar se conectar a um cluster do Amazon DocumentDB a partir de uma instância do Amazon EC2 em uma região diferente daquela do cluster — por exemplo, tentando se conectar a um cluster na região Leste dos EUA (Norte da Virgínia) (us-east-1) a partir da região Oeste dos EUA (Oregon) (us-west-2) - a conexão fracassará.
Para verificar a região do seu cluster do Amazon DocumentDB, execute o comando a seguir. A região está no endpoint.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
A saída dessa operação é semelhante à seguinte.
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
Para verificar a região da sua instância do EC2, execute o comando a seguir.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
A saída dessa operação é semelhante à seguinte.
```
[
[
"us-east-1a"
]
]
```
### Conectando-se de diferentes Amazon VPCs
**Você está tentando se conectar a um cluster do Amazon DocumentDB a partir de uma VPC diferente da Amazon VPC na qual seu cluster está implantado.**
Se o cluster do Amazon DocumentDB e a instância do Amazon EC2 estiverem no Região da AWS mesmo, mas não no mesmo Amazon VPC, você não poderá se conectar diretamente ao seu cluster do Amazon DocumentDB, a menos que o emparelhamento de VPC esteja ativado entre os dois Amazon. VPCs
Para verificar a Amazon VPC de sua instância do Amazon DocumentDB, execute o comando a seguir.
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Para verificar a Amazon VPC da sua instância do Amazon EC2, execute o comando a seguir.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### O grupo de segurança bloqueia as conexões de entrada.
**Você está tentando se conectar a um cluster do Amazon DocumentDB e o grupo de segurança do cluster não permite conexões de entrada na porta do cluster (porta padrão: 27017).**
Suponha que o cluster do Amazon DocumentDB e a instância do Amazon EC2 estejam na mesma região e Amazon VPC e usem o mesmo grupo de segurança da Amazon VPC. Se você não conseguir se conectar ao cluster do Amazon DocumentDB, a causa provável é que o grupo de segurança (ou seja, firewall) do cluster não permite conexões de entrada na porta escolhida para o cluster do Amazon DocumentDB (a porta padrão é 27017 ).
Para verificar a porta do seu cluster do Amazon DocumentDB, execute o comando a seguir.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Para obter o seu grupo de segurança do Amazon DocumentDB para o seu cluster, execute o seguinte comando.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
Para verificar as regras de entrada do seu grupo de segurança, consulte os seguintes tópicos na documentação do Amazon EC2:
+ [Autorizar tráfego de entrada para as instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Autorizar tráfego de entrada para as instâncias do Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Problema de preferência de leitura do driver Java Mongo
**As preferências de leitura do cliente não são respeitadas e alguns clientes não podem gravar no Amazon DocumentDB após o failover, a menos que sejam reinicializados.**
Esse problema, descoberto pela primeira vez no Java Mongo Driver 3.7.x, ocorre quando um cliente estabelece uma conexão com o Amazon DocumentDB usando `MongoClientSettings` e, especificamente, ao encadear o método. `applyToClusterSettings` As configurações do MongoClient cluster podem ser definidas usando alguns métodos diferentes`hosts()`, como`requiredReplicaSetName()`, `mode()` e.
Quando o cliente especifica apenas um host no método `hosts()`, o modo é definido como em `ClusterConnectionMode.SINGLE` vez de `ClusterConnectionMode.MULTIPLE` Isso faz com que o cliente desconsidere a preferência de leitura e se conecte apenas ao servidor configurado em `hosts()`. Portanto, mesmo que as configurações do cliente sejam inicializadas como abaixo, todas as leituras ainda irão para a primária em vez da secundária.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx",
"admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder -> builder
.enabled(false))
.applyToClusterSettings(builder -> builder.hosts(
Arrays.asList(serverAddress0
))
.requiredReplicaSetName("rs0"))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
**Caso de failover**
Usando as configurações de conexão do cliente acima, se houver um failover e uma atualização atrasada do registro DNS para o endpoint do gravador do cluster, o cliente ainda tentará emitir gravações no gravador antigo (agora leitor após o failover). Isso resulta em um erro do lado do servidor (não principal) que não é tratado adequadamente pelo driver Java (isso ainda está sob investigação). Assim, o cliente pode ficar em mau estado até que o servidor da aplicação seja reinicializado, por exemplo.
Há duas soluções alternativas para isso:
+ Clientes que se conectam ao Amazon DocumentDB por meio de uma cadeia de conexão não terão esse problema, pois `ClusterConnectionMode` serão configurados como `MULTIPLE` ao definir a preferência de leitura.
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
Ou usando o construtor `MongoClientSettings` com o método`applyConnectionString`.
```
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.applyConnectionString(new ConnectionString("usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred"))
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
+ Definido explicitamente de `ClusterConnectionMode` para `MULTIPLE`. Isso só é necessário ao usar `applyToClusterSettings` e `hosts().size() == 1`.
```
final ServerAddress serverAddress0 = new ServerAddress("cluster-endpoint", 27317));
final MongoCredential credential = MongoCredential.createCredential("xxx","admin", "xxxx".toCharArray());
final MongoClientSettings settings = MongoClientSettings.builder()
.credential(credential)
.readPreference(ReadPreference.secondaryPreferred())
.retryWrites(false)
.applyToSslSettings(builder → builder
.enabled(false))
.applyToClusterSettings(builder → builder
.hosts(Arrays.asList(serverAddress0))
.requiredReplicaSetName("rs0"))
.mode(ClusterConnectionMode.MULTIPLE))
.build();
MongoClient mongoClient = MongoClients.create(settings);
```
## Testar uma conexão com uma instância do Amazon DocumentDB
É possível testar sua conexão com um cluster usando ferramentas comuns do Linux ou Windows.
Em um terminal Linux ou Unix, teste a conexão inserindo o seguinte (substitua `cluster-endpoint` pelo endpoint e `port` pela porta da sua instância):
```
nc -zv cluster-endpoint port
```
Veja a seguir um exemplo de operação e o valor de retorno:
```
nc -zv docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017
Connection to docdbTest.d4c7nm7stsfc0.us-west-2.docdb.amazonaws.com 27017 port [tcp/*] succeeded!
```
## Conectar a um endpoint inválido
Ao conectar-se a um cluster do Amazon DocumentDB e usar um endpoint de cluster inválido, um erro semelhante ao seguinte será exibido.
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
O resultado se parece com:
```
MongoDB shell version v3.6
connecting to: mongodb://sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/
2018-11-14T17:21:18.516-0800 I NETWORK [thread1] getaddrinfo("sample-cluster.node.us-east-1.docdb.amazonaws.com") failed:
nodename nor servname provided, or not known 2018-11-14T17:21:18.537-0800 E QUERY [thread1] Error: couldn't initialize
connection to host sample-cluster.node.us-east-1.docdb.amazonaws.com, address is invalid :
connect@src/mongo/shell/mongo.js:237:13@(connect):1:6
exception: connect failed
```
Para obter o endpoint válido para um cluster, execute o seguinte comando:
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
Para obter o endpoint válido para uma instância, execute o seguinte comando:
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
Para obter mais informações, consulte [Noções básicas sobre endpoints do Amazon DocumentDB](endpoints.md).
## A configuração do driver afeta o número de conexões
Ao usar o driver do cliente para se conectar a um cluster do Amazon DocumentDB, é importante considerar o parâmetro de configuração `maxPoolSize`. A configuração `maxPoolSize` determina o número máximo de conexões que o driver do cliente manterá em seu pool de conexões.
# Solução de problemas de índices
Os tópicos a seguir abordam o que fazer se a criação do índice ou índice em segundo plano falhar.
**Topics**
+ [Criação de índice fracassa](#troubleshooting.index-build-fails)
+ [Problemas e falhas de latência de criação de índice em segundo plano](#troubleshooting.background-index-build-fails)
+ [Sobrecarga de índices de banco de dados](#troubleshooting-database-bloat)
## Criação de índice fracassa
O Amazon DocumentDB utiliza armazenamento local em uma instância como parte do processo de criação do índice. Você pode monitorar esse uso do disco usando a **FreeLocalStorage** CloudWatch métrica (`CloudWatch -> Metrics -> DocDB -> Instance Metrics`). Quando a criação do índice consumia todo o disco local e falhar, você receberá um erro. Ao migrar dados para o Amazon DocumentDB, recomendamos que você crie índices primeiro e, depois, insira os dados. Para obter mais informações sobre estratégias de migração e criação de índices, consulte [Migrar para o Amazon DocumentDB](docdb-migration.md) na documentação do Amazon DocumentDB e no blog: [ Migrar do MongoDB para o Amazon DocumentDB usando o método offline](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/).
Ao criar índices em um cluster existente, se a criação do índice estiver demorando mais do que o esperado ou falhando, recomendamos que você aumente a instância para criar o índice e, depois que o índice for criado, reduza novamente. O Amazon DocumentDB permite que você escale rapidamente os tamanhos das instâncias em minutos usando o Console de gerenciamento da AWS ou o. AWS CLI Para obter mais informações, consulte [Gerenciar classes de instância](db-instance-classes.md). Com a definição de preço de instâncias por segundo, você paga apenas pelo recurso usado por segundo.
## Problemas e falhas de latência de criação de índice em segundo plano
As compilações de índice em segundo plano no Amazon DocumentDB não são iniciadas até que todas as consultas na instância primária iniciadas antes do início da criação do índice sejam concluídas. Se houver uma consulta de longa duração, as compilações do índice em segundo plano serão bloqueadas até que a consulta seja concluída e, portanto, podem levar mais tempo do que o esperado para serem concluídas. Isso será verdadeiro mesmo que as coleções estejam vazias.
As compilações de índice em primeiro plano não exibem o mesmo comportamento de bloqueio. Em vez disso, as compilações de índice em primeiro plano têm um bloqueio exclusivo na coleção até que a construção do índice seja concluída. Portanto, para compilar índices em uma coleção vazia e evitar bloqueios em consultas de longa duração, sugerimos usar compilações de índice em primeiro plano.
**nota**
O Amazon DocumentDB permite que apenas uma compilação de índice de segundo plano ocorra em uma coleção em um determinado momento. Se as operações de DDL (Linguagem de definição de dados) como `createIndex()` ou `dropIndex()` ocorrerem na mesma coleção durante uma compilação de índice de segundo plano, essa compilação falhará.
## Sobrecarga de índices de banco de dados
O Amazon DocumentDB usa controle de simultaneidade de várias versões (MVCC) para gerenciar transações simultâneas. Quando os documentos são excluídos ou atualizados, suas versões anteriores permanecem em coleções e índices como versões “inativas”. O processo de coleta de resíduos recupera automaticamente o espaço dessas versões inativas para futuras operações.
A sobrecarga de índices ocorre quando os índices de uma coleção se tornam maiores devido ao acúmulo de entradas de índice inativas ou obsoletas ou à fragmentação nas páginas. O percentual relatado representa a quantidade de espaço de índices que pode ser usada por futuras entradas de índice. Essa sobrecarga consome espaço no cache e no armazenamento do buffer. Se você quiser remover a sobrecarga, precisará reconstruir os índices.
**Example Exemplo**
Execute o comando apresentado a seguir para determinar o armazenamento não utilizado do seu índice:
```
db.coll.aggregate({$indexStats:{}});
```
O resultado deve ser semelhante a este:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "devbox-test.localhost.a2z.com:27317",
"size" : NumberLong(827392),
"accesses" : {
"ops" : NumberLong(40000),
"docsRead" : NumberLong(46049),
"since" : ISODate("2025-04-03T21:44:51.251Z")
},
"cacheStats" : {
"blksRead" : NumberLong(264),
"blksHit" : NumberLong(140190),
"hitRatio" : 99.8121
},
"unusedStorageSize" : {
"unusedSizeBytes" : 409600,
"unusedSizePercent" : 49.51
}
}
```
É possível recriar índices sem tempo de inatividade usando o comando `reIndex`, que exige uma verificação de toda a coleção. Consulte [Manutenção de índices usando `reIndex`](managing-indexes.md#reIndex).
# Solução de problemas de performance e utilização de recursos
Esta seção fornece perguntas e soluções para problemas comuns de diagnóstico em implantações do Amazon DocumentDB. Os exemplos fornecidos usam o *shell do mongo* e têm escopo definido como uma instância individual. Para encontrar um endpoint de instância, consulte [Noções básicas sobre endpoints do Amazon DocumentDB](endpoints.md).
**Topics**
+ [Como determino o número de operações de inserção, atualização e exclusão realizadas na minha coleção por meio da API do Mongo?](#user-diag-performed-operations)
+ [Como faço para analisar o desempenho do cache?](#user-diag-cache-perf)
+ [Como faço para localizar e encerrar consultas bloqueadas ou de longa execução?](#user_diagnostics-query_terminating)
+ [Como posso ver um plano de consulta e otimizar uma consulta?](#user_diagnostics-query_plan)
+ [Como posso ver um plano de consulta em clusters elásticos?](#user-diagnostics-ec-query-plan)
+ [Como faço para listar todas as operações em execução em uma instância?](#user_diagnostics-list_queries)
+ [Como posso saber quando uma consulta está progredindo?](#user_diagnostics-query_progressing)
+ [Como determino por que um sistema fica lento repentinamente?](#user_diagnostics-speed_change)
+ [Como determino a causa da alta utilização de CPU em uma ou mais instâncias de cluster?](#user_diagnostics-cpu_utilization)
+ [Como posso determinar os cursores abertos em uma instância?](#user_diagnostics-open_cursors)
+ [Como determinar a versão atual do mecanismo do Amazon DocumentDB?](#user_diagnostics-engine_version)
+ [Como analiso o uso do índice e identifico índices não utilizados?](#user-diag-index-usage)
+ [Como identifico índices ausentes?](#user_diagnostics-identify_missing_indexes)
+ [Como faço para determinar a sobrecarga da coleção de banco de dados?](#performance-collection-bloat)
+ [Resumo de consultas úteis](#user_diagnostics-useful_queries)
## Como determino o número de operações de inserção, atualização e exclusão realizadas na minha coleção por meio da API do Mongo?
Para ver o número de operações de inserção, atualização e exclusão realizadas em uma determinada coleção, execute o seguinte comando nessa coleção:
```
db.collection.stats()
```
A saída deste comando descreve o seguinte no seu campo `opCounters`:
+ **numDocsIns**- O número de documentos inseridos nesta coleção. Isso inclui documentos inseridos usando os comandos `insert` e `insertMany`, bem como documentos inseridos por um upsert.
+ **numDocsUpd**- O número de atualizações de documentos nesta coleção. Isso inclui documentos atualizados usando os comandos `update` e `findAndModify`.
+ **numDocsDel**- O número de documentos excluídos dessa coleção. Isso inclui documentos excluídos usando os comandos `deleteOne`, `deleteMany`, `remove` e `findAndModify`.
+ **lastReset**: o horário em que esses contadores foram redefinidos pela última vez. As estatísticas fornecidas por esse comando são redefinidas starting/stopping ao agrupar ou escalar up/down a instância.
Um exemplo de resultado da execução `db.collection.stats()` é mostrado abaixo.
```
{
"ns" : "db.test",
"count" : ...,
"size" : ...,
"avgObjSize" : ...,
"storageSize" : ...,
"capped" : false,
"nindexes" : ...,
"totalIndexSize" : ...,
"indexSizes" : {
"_id_" : ...,
"x_1" : ...
},
"collScans" : ...,
"idxScans" : ...,
"opCounter" : {
"numDocsIns" : ...,
"numDocsUpd" : ...,
"numDocsDel" : ...
},
"cacheStats" : {
"collBlksHit" : ...,
"collBlksRead" : ..,
"collHitRatio" : ...,
"idxBlksHit" : ...,
"idxBlksRead" : ...,
"idxHitRatio" : ...
},
"lastReset" : "2022-09-02 19:41:40.471473+00",
"ok" : 1,
"operationTime" : Timestamp(1662159707, 1)
}
```
Esse comando “stats” deve ser usado ao visualizar contadores específicos da coleção para operações de inserção, atualização e exclusão por meio da API do Mongo. Outra forma de visualizar os contadores de operações específicos da coleção é habilitar a auditoria de DML. O número de operações de inserção, atualização e exclusão em todas as coleções durante intervalos de um minuto pode ser visualizado em [Monitorando o Amazon DocumentDB com CloudWatch](cloud_watch.md).
## Como faço para analisar o desempenho do cache?
A análise do desempenho do cache pode fornecer informações sobre a eficiência da recuperação de dados e o desempenho do sistema e é baseada na quantidade de dados lidos do disco em comparação aos do do cache. Fornecemos estatísticas de cache sobre o número de acessos (dados lidos do cache) e falhas de cache (dados que não são encontrados no cache e lidos do disco) para fornecer informações sobre o desempenho do cache. As estatísticas de cache de uma coleção específica podem ser encontradas executando o seguinte comando nessa coleção:
```
db.collection.stats()
```
Os valores no campo `cacheStats` de resultados desse comando fornecem estatísticas de cache para a coleção, bem como as estatísticas totais de cache para os índices criados na coleção. Essas estatísticas estão listadas abaixo:
+ **`collBlksHit`**: número de blocos lidos do cache durante as operações nessa coleção.
+ **`collBlksRead`**: número de blocos lidos do disco (falha de cache) durante as operações nessa coleção.
+ **`collHitRatio`**: taxa de acertos do cache para essa coleção (`100 * [collBlksHit / (collBlksHit + collBlksRead)]`).
+ **`idxBlksHit`**: número de blocos lidos do cache para qualquer índice criado nessa coleção.
+ **`idxBlksRead`**: número de blocos lidos do disco (falha de cache) para qualquer índice criado nessa coleção.
+ **`idxHitRatio`**: taxa de acerto do cache para os índices criados nessa coleção (`100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]`).
+ **`lastReset`**: horário em que essas estatísticas foram redefinidas pela última vez. As estatísticas fornecidas pelo `db.collection.stats()` são redefinidas quando starting/stopping o cluster é escalado ou up/down a instância.
Um detalhamento dos campos `idxBlksHit` e `idxBlksRead` de cada índice também pode ser encontrado usando-se o comando `indexStats`. As estatísticas de cache específicas do índice podem ser encontradas executando-se o seguinte comando:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
Para cada índice, as seguintes estatísticas de cache podem ser encontradas no campo `cacheStats`:
+ **`blksHit`**: número de blocos lidos do cache para esse índice.
+ **`blksRead`**: número de blocos lidos do disco para esse índice.
+ **`blksHitRatio`**: taxa de acertos do cache arredondada para quatro casas decimais, calculada por `100 * [blksHit / (blksHit + blksRead)]`.
## Como faço para localizar e encerrar consultas bloqueadas ou de longa execução?
As consultas de usuário podem ser executadas lentamente devido a um plano de consulta pouco ideal ou podem ser bloqueadas devido à contenção de recursos.
Para encontrar consultas de longa execução que ficam lentas devido a um plano de consulta pouco ideal ou consultas bloqueadas devido à contenção de recursos, use o comando `currentOp`. É possível filtrar o comando para ajudar a refinar a lista de consultas relevantes para serem encerradas. É necessário ter `opid` associado à consulta de longa duração para poder encerrar a consulta.
A consulta a seguir usa o comando `currentOp` para listar todas as consultas que estão bloqueadas ou em execução por mais de 10 segundos.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or: [
{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0, opid: 1, secs_running: 1}}],
cursor: {}
});
```
Depois, você pode restringir a consulta para encontrar o `opid` de uma consulta em execução por mais de 10 segundos e encerrá-lo.
**Para localizar e encerrar uma consulta em execução por mais de 10 segundos**
1. Encontre o `opid` da consulta.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or:
[{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}}],
cursor: {}
});
```
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 24646,
"secs_running" : 12
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
1. Encerre a consulta usando a operação `killOp`.
```
db.adminCommand({killOp: 1, op: 24646});
```
## Como posso ver um plano de consulta e otimizar uma consulta?
Se uma consulta for executada lentamente, pode ser porque a execução da consulta requer uma verificação completa da coleção para escolher os documentos relevantes. Às vezes, criar índices apropriados permitirá que a consulta seja executada mais rapidamente. Para detectar esse cenário e decidir os campos nos quais criar os índices, use o comando `explain`.
**nota**
O Amazon DocumentDB emula a API do MongoDB 3.6 em um mecanismo de banco de dados com propósito específico que utiliza um sistema de armazenamento distribuído, tolerante a falhas e de autorrecuperação. Como resultado, os planos de consulta e a saída de `explain()` podem diferir entre o Amazon DocumentDB e o MongoDB. Os clientes que desejam ter controle sobre seu plano de consulta podem usar o operador `$hint` para impor a seleção de um índice preferencial.
Execute a consulta que você deseja melhorar com o comando `explain` da seguinte forma.
```
db.runCommand({explain: {}})
```
Veja a seguir um exemplo de operação.
```
db.runCommand({explain:{
aggregate: "sample-document",
pipeline: [{$match: {x: {$eq: 1}}}],
cursor: {batchSize: 1}}
});
```
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "COLLSCAN"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
A saída acima indica que o estágio `$match` exige a verificação de toda a coleção e a verificação se o campo `"x"` em cada documento é igual a 1. Se houver muitos documentos na coleção, a verificação da coleção (e, portanto, o desempenho geral da consulta) serão muito lentos. Assim, a presença de `"COLLSCAN"` na saída do comando `explain` indica que o desempenho da consulta pode ser aprimorado com a criação de índices apropriados.
Neste exemplo, a consulta verifica se o campo `"x"` é igual a 1 em todos os documentos. Portanto, criar um campo de índice no `"x"` permite que a consulta evite a verificação completa da coleção e use o índice para retornar os documentos relevantes mais cedo.
Depois de criar um índice no campo `"x"`, a saída `explain` será a seguinte.
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "x_1",
"direction" : "forward"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
A criação de um índice no campo `"x"` permite que o estágio `$match` use uma varredura de índice para reduzir o número de documentos nos quais o predicado `"x = 1"` precisa ser avaliado.
Para pequenas coleções, o processador de consultas do Amazon DocumentDB pode optar por não usar um índice se os ganhos de desempenho forem negligenciáveis.
## Como posso ver um plano de consulta em clusters elásticos?
Para examinar um plano de consulta em clusters elásticos, use o comando `explain`. Veja a seguir um exemplo de operação `explain` em uma consulta de busca direcionada a uma coleção fragmentada:
```
db.runCommand(
{
explain: { find: "cities", filter: {"name": "Seoul"}}
}
)
```
**nota**
O Amazon DocumentDB emula o MongoDB em um mecanismo de banco de dados com propósito específico. Como resultado, os planos de consulta e a saída de `explain()` podem diferir entre o Amazon DocumentDB e o MongoDB. É possível controlar seu plano de consulta com o uso do operador `$hint` para impor a seleção de um índice preferencial.
A saída dessa operação pode ser semelhante ao seguinte (formato JSON):
```
{
"queryPlanner" : {
"elasticPlannerVersion" : 1,
"winningPlan" : {
"stage" : "SINGLE_SHARD",
"shards" : [
{
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "SHARD_MERGE",
"shards" : [
{
"shardName" : "f2cf5cfd-fe9c-40ca-b4e5-298ca0d11111",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "8f3f80e2-f96c-446e-8e9d-aab8c7f22222",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 21
}
]
}
},
{
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a033333",
"plannerVersion" : 1,
"namespace" : "population.cities",
"winningPlan" : {
"stage" : "PARTITION_MERGE",
"inputStages" : [
{
"stage" : "COLLSCAN",
"partitionCount" : 22
}
]
}
}
]
},
"shardName" : "32c5a06f-1b2b-4af1-8849-d7c4a0f3fb58"
}
]
}
},
"serverInfo" : {
"host" : "example-4788267630.us-east-1.docdb-elastic.amazonaws.com:27017",
"version" : "5.0.0"
},
"ok" : 1,
"operationTime" : Timestamp(1695097923, 1)
}
```
A saída anterior mostra o plano de consulta para a consulta `find` em um cluster de três fragmentos. Cada fragmento tem várias partições de dados que podem ter diferentes estágios de entrada. Neste exemplo, um “COLLSCAN “(uma varredura de coleções) é executado em todas as partições antes que os resultados sejam mesclados no estágio “PARTITION\$1MERGE” dentro de cada fragmento. Os resultados dos fragmentos são, então, mesclados no estágio “SHARD\$1MERGE” antes de serem enviados de volta ao cliente.
## Como faço para listar todas as operações em execução em uma instância?
Como usuário ou usuário principal, muitas vezes você deseja listar todas as operações atuais em execução em uma instância para fins de diagnóstico e solução de problemas. (Para obter informações sobre o gerenciamento de usuários, consulte [Gerenciar usuários do Amazon DocumentDB](security.managing-users.md).)
Com o shell do `mongo`, você pode usar a seguinte consulta para listar todas as operações em execução em uma instância do Amazon DocumentDB.
```
db.adminCommand({currentOp: 1, $all: 1});
```
A consulta retorna a lista completa de todas as consultas do usuário e tarefas internas do sistema atualmente em operação na instância.
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"inprog" : [
{
"desc" : "INTERNAL"
},
{
"desc" : "TTLMonitor",
"active" : false
},
{
"client" : ...,
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 195,
"ns" : "admin.$cmd",
"command" : {
"currentOp" : 1,
"$all" : 1
},
"op" : "command",
"$db" : "admin",
"secs_running" : 0,
"microsecs_running" : NumberLong(68),
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
}
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionA"
},
"secs_running": 3,
"microsecs_running": NumberLong(3123456)
},
{
"desc": "GARBAGE_COLLECTION",
"garbageCollection": {
"databaseName": "testdb",
"collectionName": "testCollectionB"
},
"secs_running": 4,
"microsecs_running": NumberLong(4123456)
}
],
"ok" : 1
}
```
Estes são valores válidos para o campo `"desc"`:
+ **INTERNAL** — tarefas internas do sistema, como a limpeza do cursor ou tarefas de limpeza obsoletas do usuário.
+ **TTLMonitor**: thread de monitoramento Time to Live (TTL - vida útil). O status de execução é refletido no campo `"active"`.
+ **GARBAGE\$1COLLECTION**: thread do coletor de resíduos interno.
+ **CONN** — consulta do usuário.
+ **CURSOR** — a operação é um cursor inativo esperando que o usuário chame o comando "getMore" para obter o próximo lote de resultados. Nesse estado, o cursor está consumindo memória, mas não está consumindo nenhuma computação.
A saída anterior também lista todas as consultas do usuário em execução no sistema. Cada consulta de usuário é executada no contexto de um banco de dados e uma coleção, e a união desses dois é chamada de *namespace*. O namespace de cada consulta do usuário está disponível no campo `"ns"`.
Às vezes, você precisa listar todas as consultas de usuário em execução em um determinado namespace. Portanto, a saída anterior deve ser filtrada no campo `"ns"`. Um exemplo de consulta para alcançar a saída para filtrar é o seguinte. A consulta lista todas as consultas de usuário em execução no momento no banco de dados `"db"` e na coleção `"test"` (ou seja, o namespace `"db.test"`).
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$match: {ns: {$eq: "db.test"}}}],
cursor: {}
});
```
Como usuário principal do sistema, você pode ver as consultas de todos os usuários e também todas as tarefas internas do sistema. Todos os outros usuários só podem ver suas respectivas consultas.
Se o número total de consultas e tarefas internas do sistema exceder o tamanho do lote padrão do cursor, o shell do `mongo` gerará automaticamente um objeto iterador `'it'` para visualizar o resto dos resultados. Continue executando o comando `'it'` até que todos os resultados sejam esgotados.
## Como posso saber quando uma consulta está progredindo?
As consultas do usuário podem ficar lentas devido a um plano de execução de consulta pouco satisfatório ou ficar bloqueadas devido à contenção de recursos. Depurar essas consultas é um processo de várias etapas que pode exigir que a mesma etapa seja executada várias vezes.
A primeira etapa da depuração é listar todas as consultas que estão bloqueada ou de longa execução. A consulta a seguir lista todas as consultas de usuário que estão em execução por mais de 10 segundos ou que estão aguardando recursos.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
Repita a consulta anterior periodicamente para determinar se a lista de consultas muda e identificar as consultas bloqueadas ou de longa execução.
Se o documento de saída da consulta em questão tiver um campo `WaitState`, isso indica que a contenção de recursos é o motivo pelo qual a consulta está lenta ou bloqueada. A contenção de recursos pode ocorrer devido a E/S, tarefas internas do sistema ou outras consultas do usuário.
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 201,
"command" : {
"aggregate" : ...
},
"secs_running" : 208,
"WaitState" : "IO"
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
E/S poderá ser um gargalo se houver muitas consultas em diferentes coleções em execução simultaneamente na mesma instância ou se o tamanho da instância for muito pequeno para o conjunto de dados no qual a consulta está sendo executada. Se as consultas forem somente de leitura, será possível atenuar a situação anterior separando as consultas de cada coleção em réplicas separadas. Para atualizações simultâneas em diferentes coleções ou quando o tamanho da instância for muito pequeno para o conjunto de dados, é possível mitigar aumentando a instância.
Se a contenção de recursos ocorrer devido a outra consulta do usuário, o campo `"blockedOn"` no documento de saída terá o `"opid"` da consulta que está afetando essa consulta. Com o `"opid"` siga a cadeia de campos `"WaitState"` e `"blockedOn"` de todas as consultas para encontrar a consulta à frente da cadeia.
Se a tarefa à frente da cadeia for uma tarefa interna, a única mitigação nesse caso seria encerrar a consulta e executá-la novamente depois de algum tempo.
Veja a seguir um exemplo de saída em que a consulta de busca é bloqueada em um bloqueio de coleção que pertence a outra tarefa.
```
{
"inprog" : [
{
"client" : "...",
"desc" : "Conn",
"active" : true,
"killPending" : false,
"opid" : 75,
"ns" : "...",
"command" : {
"find" : "...",
"filter" : {
}
},
"op" : "query",
"$db" : "test",
"secs_running" : 9,
"microsecs_running" : NumberLong(9449440),
"threadId" : 24773,
"clientMetaData" : {
"application" : {
"name" : "MongoDB Shell"
},
"driver" : {
...
},
"os" : {
...
}
},
"WaitState" : "CollectionLock",
"blockedOn" : "INTERNAL"
},
{
"desc" : "INTERNAL"
},
{
"client" : "...",
...
"command" : {
"currentOp" : 1
},
...
}
],
"ok" : 1
}
```
Se `"WaitState"` tiver valores `"Latch"`, `"SystemLock"`, `"BufferLock"`, `"BackgroundActivity"` ou `"Other"`, a origem da contenção de recursos serão as tarefas internas do sistema. Se a situação continuar por um longo período, a única atenuação será encerrar a consulta e executá-la novamente mais tarde.
## Como determino por que um sistema fica lento repentinamente?
Veja a seguir alguns motivos comuns para uma desaceleração do sistema:
+ Contenção excessiva de recursos entre consultas simultâneas
+ O número de consultas simultâneas ativas aumentando ao longo do tempo
+ Tarefas internas do sistema, como `"GARBAGE_COLLECTION"`
Para monitorar o uso do sistema ao longo do tempo, execute a seguinte consulta `"currentOp"` periodicamente e gere a saída dos resultados em um armazenamento externo. A consulta conta o número de consultas e operações em cada namespace no sistema. É possível analisar os resultados do uso do sistema para compreender a carga no sistema e tomar a medida apropriada.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
Essa consulta retorna um agregado de todas as consultas em execução em cada namespace e em todas as tarefas internas do sistema, e o número exclusivo de estados de espera, se houver, por namespace.
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"_id" : {
"desc" : "Conn",
"ns" : "db.test",
"WaitState" : "CollectionLock"
},
"count" : 2
},
{
"_id" : {
"desc" : "Conn",
"ns" : "admin.$cmd"
},
"count" : 1
},
{
"_id" : {
"desc" : "TTLMonitor"
},
"count" : 1
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
Na saída anterior, duas consultas de usuário no namespace `"db.test"` estão bloqueadas no bloqueio da coleção: uma consulta no namespace `"admin.$cmd"` e uma tarefa interna `"TTLMonitor"`.
Se a saída indicar muitas consultas com estados de espera de bloqueio, consulte [Como faço para localizar e encerrar consultas bloqueadas ou de longa execução?](#user_diagnostics-query_terminating)
## Como determino a causa da alta utilização de CPU em uma ou mais instâncias de cluster?
As seções a seguir podem ajudar você a identificar a causa da alta utilização da CPU da instância. Os resultados podem variar dependendo da workload.
+ Para determinar por que uma instância está sendo executada lentamente de forma repentina, consulte [Como determino por que um sistema fica lento repentinamente?](#user_diagnostics-speed_change)
+ Para identificar e encerrar consultas de longa execução em uma instância específica, consulte [Como faço para localizar e encerrar consultas bloqueadas ou de longa execução?](#user_diagnostics-query_terminating)
+ Para entender se uma consulta está progredindo, consulte [Como posso saber quando uma consulta está progredindo?](#user_diagnostics-query_progressing)
+ Para determinar por que uma consulta leva muito tempo para ser executada, consulte [Como posso ver um plano de consulta e otimizar uma consulta?](#user_diagnostics-query_plan)
+ Para rastrear consultas demoradas ao longo do tempo, consulte [Definir o perfil das operações do Amazon DocumentDB](profiling.md).
Dependendo do motivo da alta utilização da CPU da instância, executar uma ou mais das ações a seguir pode ajudar.
+ Se a instância primária apresentar alta utilização de CPU, mas as instâncias de réplica não, considere distribuir o tráfego de leitura entre réplicas por meio de configurações de preferência de leitura do cliente (por exemplo, `secondaryPreferred`). Para obter mais informações, consulte [Conectar-se ao Amazon DocumentDB como um conjunto de réplicas](connect-to-replica-set.md).
O uso de réplicas para leituras pode fazer melhor uso dos recursos do cluster, permitindo que a instância primária processe mais tráfego de gravação. As leituras de réplicas do são eventualmente consistentes.
+ Se a alta utilização da CPU for resultado da workload de gravação, alterar o tamanho das instâncias do cluster para um tipo de instância maior aumentará o número de núcleos de CPU disponíveis para atender à workload. Para obter mais informações, consulte [Instâncias](what-is.md#what-is-db-instances) e [Especificações de classe de instância](db-instance-classes.md#db-instance-class-specs).
+ Se todas as instâncias de cluster exibirem alta utilização de CPU e a workload estiver usando réplicas para leituras, adicionar mais réplicas ao cluster aumentará os recursos disponíveis para o tráfego de leitura. Para obter mais informações, consulte [Adicionar uma instância do Amazon DocumentDB a um cluster](db-instance-add.md).
## Como posso determinar os cursores abertos em uma instância?
Quando estiver conectado a uma instância do Amazon DocumentDB, será possível usar o comando `db.runCommand("listCursors")` para listar os cursores abertos nessa instância. Há um limite de até 4.560 cursores ativos abertos a qualquer momento em uma determinada instância do Amazon DocumentDB, dependendo do tipo de instância. Em geral, recomendamos fechar os cursores que não estão mais em uso, porque os cursores utilizam os recursos em uma instância e têm um limite superior. Consulte [Cotas e limites do Amazon DocumentDB](limits.md) para obter os limites específicos.
```
db.runCommand("listCursors")
```
## Como determinar a versão atual do mecanismo do Amazon DocumentDB?
Para determinar a versão atual do mecanismo do Amazon DocumentDB, execute o seguinte comando.
```
db.runCommand({getEngineVersion: 1})
```
A saída dessa operação é semelhante ao seguinte (formato JSON).
```
{ "engineVersion" : "2.x.x", "ok" : 1 }
```
**nota**
A versão do mecanismo do Amazon DocumentDB 3.6 é 1.x.x, a versão do mecanismo do Amazon DocumentDB 4.0 é 2.x.x, a versão do mecanismo do Amazon DocumentDB 5.0 é 3.x.x e a versão do mecanismo do Amazon DocumentDB 8.0 é 4.x.x.
## Como analiso o uso do índice e identifico índices não utilizados?
Para identificar os índices de uma determinada coleção, execute o seguinte comando:
```
db.collection.getIndexes()
```
Para analisar quantos índices estão sendo usados durante as operações realizadas nas coleções, os comandos `collStats` e `indexStats` podem ser usados. Para visualizar o número total de varreduras realizadas usando índices (varreduras de índices) em comparação com o número de varreduras realizadas sem um índice (varreduras de coleções), execute o seguinte comando:
```
db.collection.stats()
```
O resultado desse comando inclui os seguintes valores:
+ **`idxScans`**: número de varreduras realizadas nessa coleção usando um índice.
+ **`collScans`**: número de varreduras realizadas nessa coleção sem usar um índice. Essas digitalizações envolveriam a análise dos documentos da coleção, um de cada vez.
+ **`lastReset`**: horário em que esses contadores foram redefinidos pela última vez. As estatísticas fornecidas por esse comando são redefinidas starting/stopping ao agrupar ou escalar up/down a instância.
Um detalhamento de quanto cada índice é usado pode ser encontrado no resultado do comando a seguir. É uma prática recomendada identificar e remover regularmente índices não utilizados para melhorar o desempenho e reduzir custos, pois isso elimina a computação e o armazenamento desnecessários e o I/Os uso para manter os índices.
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
O resultado desse comando fornece os seguintes valores para cada índice criado na coleção:
+ **`ops`** - número de operações que usaram o índice. Se sua workload estiver sendo executada por um tempo suficientemente longo e você estiver confiante de que ela está em um estado estável, um valor zero de `ops` indicaria que o índice não é usado.
+ **`numDocsRead`**: número de documentos lidos durante as operações usando esse índice.
+ **`since`** - tempo desde que o Amazon DocumentDB começou a coletar estatísticas sobre o uso do índice, que geralmente é o valor desde a última reinicialização ou ação de manutenção do banco de dados.
+ **`size`** - tamanho desse índice em bytes.
O exemplo a seguir é um exemplo de saída da execução do comando acima:
```
{
"name" : "_id_",
"key" : {
"_id" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
{
"name" : "x_1",
"key" : {
"x" : 1
},
"host" : "example-host.com:12345",
"size" : NumberLong(...),
"accesses" : {
"ops" : NumberLong(...),
"docsRead" : NumberLong(...),
"since" : ISODate("...")
},
"cacheStats" : {
"blksRead" : NumberLong(...),
"blksHit" : NumberLong(...),
"hitRatio" : ...
}
}
```
Para determinar o tamanho geral do índice para uma coleção, execute o seguinte comando:
```
db.collection.stats()
```
Para descartar um índice não utilizado, execute o seguinte comando:
```
db.collection.dropIndex("indexName")
```
## Como identifico índices ausentes?
É possível usar o [profiler do Amazon DocumentDB para registrar consultas lentas em log](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html). Uma consulta que aparece repetidamente no log de consulta lenta pode indicar que um índice adicional é necessário para melhorar o desempenho dessa consulta.
É possível identificar oportunidades para índices úteis procurando consultas de execução longa que tenham um ou mais estágios que executem pelo menos um estágio `COLLSCAN`, o que significa que o estágio de consulta tem que ler todos os documentos na coleção para fornecer uma resposta à consulta.
O exemplo a seguir mostra uma consulta em uma coleção de corridas de táxi que foi executada em uma coleção grande.
```
db.rides.count({"fare.totalAmount":{$gt:10.0}}))
```
Para executar este exemplo, a consulta tinha que realizar uma varredura na coleção (ou seja, ler todos os documentos da coleção), pois não há índice no campo `fare.totalAmount`. A saída do profiler do Amazon DocumentDB para essa consulta tem uma aparência semelhante à seguinte:
```
{
...
"cursorExhausted": true,
"nreturned": 0,
"responseLength": 0,
"protocol": "op_query",
"millis": 300679,
"planSummary": "COLLSCAN",
"execStats": {
"stage": "COLLSCAN",
"nReturned": "0",
"executionTimeMillisEstimate": "300678.042"
},
"client": "172.31.5.63:53878",
"appName": "MongoDB Shell",
"user": "example"
}
```
Para acelerar a consulta neste exemplo, convém criar um índice no `fare.totalAmount`, como mostrado abaixo.
```
db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
```
**nota**
Os índices criados em primeiro plano (ou seja, se a opção `{background:true}` não foi fornecida ao criar o índice) usam um bloqueio de gravação exclusivo, o que impede que as aplicações gravem dados na coleção até que a compilação do índice seja concluída. Esteja ciente desse possível impacto ao criar índices em clusters de produção. Ao criar índices, recomendamos a configuração `{background:true}`.
Em geral, convém criar índices em campos com cardinalidade alta (por exemplo, um grande número de valores exclusivos). Criar um índice em um campo com baixa cardinalidade pode resultar em um índice grande que não é usado. O otimizador de consulta do Amazon DocumentDB considera o tamanho geral da coleção e a seletividade dos índices ao criar um plano de consulta. Às vezes, você verá o processador de consultas selecionar um `COLLSCAN` mesmo quando um índice estiver presente. Isso acontece quando o processador de consultas estima que a utilização do índice não produzirá uma vantagem de desempenho sobre a varredura de toda a coleção. Se você quiser forçar o processador de consultas a utilizar um índice específico, use o operador `hint()` como mostrado abaixo.
```
db.collection.find().hint("indexName")
```
## Como faço para determinar a sobrecarga da coleção de banco de dados?
A sobrecarga da coleção ocorre quando seu tamanho se torna maior devido ao acúmulo de entradas de índice documentos inativos ou obsoletos ou à fragmentação nas páginas do banco de dados. O percentual relatado representa a quantidade de espaço de documentos que pode ser usada por futuros documentos. Essa sobrecarga consome espaço no cache e no armazenamento do buffer. Para remover o inchaço, as coleções devem ser recarregadas por meio dump/restore ou usando um loop de migração e alternância durante uma janela de manutenção.
**Example Exemplo**
Execute o comando a seguir para determinar o armazenamento não utilizado da sua coleção:
```
db.runCommand({collStats:'coll'})
```
O resultado deve ser semelhante a este:
```
{
"ns" : "test.coll",
"count" : 7500,
"size" : 23250,
"avgObjSize" : 31,
"storageSize" : 106496,
"unusedStorageSize" : {
"unusedBytes" : 16384,
"unusedPercent" : 25.12
},
"compression" : {
"enable" : false
},
"capped" : false,
"nindexes" : 1,
"totalIndexSize" : 57344,
"indexSizes" : {
"_id_" : 57344
},
"collScans" : 4,
"idxScans" : 10000,
"opCounter" : {
"numDocsIns" : 1000,
"numDocsUpd" : 0,
"numDocsDel" : 250
},
"cacheStats" : {
"collBlksHit" : 3570,
"collBlksRead" : 8,
"collHitRatio" : 99.7765,
"idxBlksHit" : 12293,
"idxBlksRead" : 6,
"idxHitRatio" : 99.9513
},
"lastReset" : "2024-12-18 00:30:21.552019+00",
"ok" : 1,
"operationTime" : Timestamp(1734632375, 1)
}
```
## Resumo de consultas úteis
As consultas a seguir podem ser úteis para monitorar o desempenho e a utilização de recursos no Amazon DocumentDB.
+ Use o comando a seguir para visualizar estatísticas sobre uma coleção específica, incluindo contadores de operação, estatísticas de cache, estatísticas de acessos e estatísticas de tamanho:
```
db.collection.stats()
```
+ Use o comando a seguir para visualizar estatísticas sobre cada índice criado em uma coleção, incluindo o tamanho do índice, estatísticas de cache específicas do índice e estatísticas de uso do índice:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
+ Use a consulta a seguir para listar todas as atividades.
```
db.adminCommand({currentOp: 1, $all: 1});
```
+ O código a seguir lista todas as consultas bloqueadas ou de longa execução.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {}},
{$match: {$or: [{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}},
{$project: {_id:0,
opid: 1,
secs_running: 1,
WaitState: 1,
blockedOn: 1,
command: 1}}],
cursor: {}
});
```
+ O código a seguir encerra uma consulta.
```
db.adminCommand({killOp: 1, op: });
```
+ Use o código a seguir para obter uma visualização agregada do estado do sistema.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
# Coleta de resíduos no Amazon DocumentDB
O Amazon DocumentDB implementa uma arquitetura de banco de dados de controle de simultaneidade de várias versões (MVCC) que cria novas versões de entradas de documentos e índices para cada operação de atualização. Essa arquitetura permite o isolamento de transações, impedindo que as alterações de uma transação apareçam em outra.
**Topics**
+ [Entendendo a coleta de lixo no Amazon DocumentDB](#understanding-garbage-collection)
+ [Processo de coleta de resíduos](#garbage-collection-process)
+ [Arquitetura de armazenamento e armazenamento estendido](#storage-architecture)
+ [Monitoramento da coleta de resíduos](#monitoring-garbage-collection)
+ [Exemplo de saída CollStats](#example-collstats-output)
+ [Perguntas frequentes](#garbage-collection-faq)
## Entendendo a coleta de lixo no Amazon DocumentDB
A coleta de resíduos (GC) é um processo automatizado em segundo plano que mantém a performance e a disponibilidade ideais do sistema no Amazon DocumentDB. Como muitos bancos de dados modernos, a arquitetura MVCC do Amazon DocumentDB cria novas versões de documentos e índices a cada atualização. Cada operação de gravação consome um ID MVCC exclusivo de um contador finito. Eles IDs identificam a qual transação uma versão do documento pertence e se ela foi confirmada ou revertida. Com o tempo, essas versões antigas e seu MVCC IDs se acumulam, exigindo limpeza para evitar a degradação do desempenho.
### Funções da coleta de resíduos
O coletor de resíduos tem três funções essenciais:
+ **Recuperar espaço de armazenamento**: ele remove versões obsoletas de documentos e índices que não sejam mais necessárias para consultas ativas, liberando espaço para futuras operações de gravação.
+ **Evita o estouro do ID do MVCC — Evita o estouro** do ID do MVCC gerenciando o contador finito do MVCC. IDs Sem esse gerenciamento, o contador acabaria atingindo seu limite, forçando o banco de dados a entrar em um modo temporário somente para leitura até IDs ser reciclado.
+ **Manter a performance da consulta**: ele mantém a performance ideal da consulta eliminando versões inativas de documentos que, de outra forma, se acumulariam e retardariam o processamento de consultas.
## Processo de coleta de resíduos
O processo de GC opera por coleção e pode ter vários processos sendo executados simultaneamente em coleções diferentes. O processo consiste em quatro fases sequenciais:
1. **Identificação**: o sistema identifica versões de documentos e índices que não são mais referenciadas por transações ou consultas ativas.
1. **Carregamento na memória**: os documentos antigos e as entradas de índice são carregados na memória se ainda não estiverem presentes.
1. **Exclusão**: as versões obsoletas são excluídas permanentemente para recuperar espaço de armazenamento.
1. **Reciclagem de ID MVCC** — O sistema recicla o MVCC de versões IDs excluídas para novas operações.
Quando a coleta de lixo conclui o processamento das versões antigas do documento, ela remove o MVCC IDs mais antigo do sistema. Essa limpeza é crucial para evitar o estouro de IDs do MVCC ao reciclar o MVCC IDs, disponibilizando-o para novas operações de gravação em todo o cluster. Sem esse processo de reciclagem, o sistema acabaria por esgotar seu contador finito de IDs do MVCC e entrar em um estado somente de leitura.
### Programação da coleta de resíduos
A coleta de resíduos é executada automaticamente em segundo plano, em intervalos periódicos. O tempo e a frequência se ajustam dinamicamente com base na carga do sistema, nos recursos disponíveis, no volume de gravação e nos níveis de consumo de IDs do MVCC. Durante a alta atividade de gravação, o processo de GC é executado com mais frequência para gerenciar o aumento do número de versões do documento.
## Arquitetura de armazenamento e armazenamento estendido
O Amazon DocumentDB usa uma arquitetura de armazenamento sofisticada que separa o armazenamento de documentos em dois segmentos distintos:
### Segmento de armazenamento básico
O segmento de armazenamento básico contém os dados e metadados do documento primário. Esse segmento armazena:
+ Conteúdo do documento que se encaixa no tamanho padrão da página (8 KB).
+ Documente os metadados e estruture as informações.
+ Índices primários e suas entradas.
+ Estatísticas e configuração em nível de coleção.
### Segmento de armazenamento estendido
O segmento de armazenamento estendido utiliza um grande repositório especializado de objetos de documentos, projetado para lidar com documentos que excedem o tamanho padrão da página de armazenamento. Esse segmento fornece:
+ **Manipulação eficiente de documentos grandes** — Documentos maiores que o limite básico de armazenamento são movidos automaticamente para o segmento de armazenamento estendido.
+ **Layout de armazenamento otimizado** — O segmento usa um formato de armazenamento diferente, otimizado para objetos grandes, reduzindo a fragmentação e melhorando os padrões de acesso.
+ **Coleta de lixo independente** — O segmento de armazenamento estendido tem seu próprio processo de coleta de lixo que pode ser executado independentemente da limpeza do armazenamento básico.
+ **Acesso transparente** — os aplicativos acessam documentos grandes sem precisar saber qual segmento de armazenamento contém os dados.
O segmento de armazenamento estendido é particularmente benéfico para:
+ Coleções com documentos contendo grandes matrizes incorporadas.
+ Documentos com extensas estruturas aninhadas.
+ Coleções que armazenam dados binários ou grandes campos de texto.
+ Aplicativos com tamanhos de documentos mistos em que alguns documentos excedem significativamente o tamanho médio.
## Monitoramento da coleta de resíduos
### Métricas em nível de cluster
**`AvailableMVCCIds`**
+ **Localização** — Amazon CloudWatch
+ **Descrição** — Um contador que mostra o número de operações de gravação restantes disponíveis a partir de um limite máximo de 1,8 bilhão. Quando esse contador chega a zero, seu cluster entra no modo somente leitura até IDs ser recuperado e reciclado. O contador diminui a cada operação de gravação e aumenta à medida que a coleta de lixo recicla o MVCC antigo. IDs
+ **Recomendação**: define um alarme quando o valor cair abaixo de 1,3 bilhão. Esse aviso antecipado permite que você execute as etapas recomendadas discutidas posteriormente.
**`LongestActiveGCRuntime`**
+ **Localização** — Amazon CloudWatch
+ **Descrição**: duração em segundos do processo de coleta de resíduos ativo mais longo. Atualiza a cada minuto e rastreia somente as operações ativas, excluindo os processos concluídos dentro da janela de um minuto.
+ **Recomendação** — compare com dados `gcRuntimeStats` históricos para identificar comportamentos anormais de coleta de lixo, como tempos de execução estendidos durante exclusões em massa.
### Métricas de nível de coleção
**`MVCCIDStats: MVCCIdScale`**
+ **Localização**: comando collStats do banco de dados
+ **Descrição**: mede a idade do ID do MVCC em uma escala de 0 a 1, em que 1 indica a idade máxima antes de um cluster entrar em um estado somente de leitura. Use essa métrica ao lado `AvailableMVCCIds` para identificar coleções contendo o MVCC mais antigo IDs que estão envelhecendo o cluster.
+ **Recomendação**: mantenha valores abaixo de 0,3 para cada coleção.
**`gcRuntimeStats`**
+ **Localização**: comando collStats do banco de dados
+ **Descrição**: fornece um histórico de dois meses das métricas de coleta de resíduos, incluindo o total de execuções, a duração média e a duração máxima. Inclui apenas operações de coleta de resíduos com duração superior a cinco minutos para garantir estatísticas significativas.
**Importante**
`gcRuntimeStats`,`documentFragmentStats`, e divisão das métricas de nível de coleção em `storageSegmentBase` e só `storageSegmentExtended` estão disponíveis para o Amazon DocumentDB 8.0.
**`storageSizeStats`**
+ **Localização**: comando collStats do banco de dados
+ **Descrição** — fornece uma análise detalhada da utilização do armazenamento em diferentes segmentos de armazenamento:
+ `storageSegmentBase`— Armazenamento usado pelo segmento de armazenamento básico para documentos padrão
+ `storageSegmentExtended`— Armazenamento usado pelo segmento de armazenamento estendido para documentos grandes
+ **Uso** — ajuda a identificar coleções com armazenamento significativo de documentos grandes e a entender os padrões de distribuição de armazenamento.
**`unusedStorageSize`** (nível de coleção)
+ **Localização**: comando collStats do banco de dados
+ **Descrição**: estima o espaço de armazenamento não utilizado em uma coleção com base nas estatísticas amostradas. Ela inclui o espaço de documentos excluídos e segmentos vazios. A métrica fornece totais combinados e detalhamentos por segmento:
+ Combinado `unusedBytes` e `unusedPercent` em todos os segmentos de armazenamento
+ `storageSegmentBase`— Espaço não utilizado, especificamente no segmento de armazenamento básico
+ `storageSegmentExtended`— Espaço não utilizado, especificamente no segmento de armazenamento estendido
**`documentFragmentStats`**
+ **Localização**: comando collStats do banco de dados
+ **Descrição** — Fornece informações detalhadas sobre fragmentos de documentos e dados mortos nas coleções. Fragmentos de documentos representam as unidades de armazenamento interno usadas pelo mecanismo de banco de dados, e fragmentos mortos indicam dados que não estão mais acessíveis, mas que ainda não foram recuperados. Essa métrica inclui:
+ `totalDocFragmentsCount`— Número total de fragmentos de documentos na coleção
+ `deadDocFragmentsCount`— Número de fragmentos contendo dados mortos (inacessíveis)
+ `deadDocFragmentsPercent`— Porcentagem de fragmentos que contêm dados mortos
+ `deadDocFragmentBytes`— Estimativa de bytes consumidos por fragmentos de documentos mortos
+ Detalhamento por segmento para e `storageSegmentBase` `storageSegmentExtended`
+ **Uso** — Monitore essa métrica para entender a eficácia da coleta de lixo e identificar as coleções que podem se beneficiar das operações de manutenção. Altas porcentagens de fragmentos mortos indicam que a coleta de lixo pode estar ficando para trás ou que a coleta se beneficiaria com a otimização.
### Métricas de nível de índice
**`unusedStorageSize`** (nível de índice)
+ **Localização**: comando indexStats do banco de dados
+ **Descrição**: estima o espaço de armazenamento não utilizado em um índice com base nas estatísticas amostradas. Ela inclui o espaço de entradas de índice obsoletas e segmentos vazios.
+ **Recomendação**: use o comando `reIndex` para reconstruir índices sem tempo de inatividade e recuperar espaço não utilizado. Para obter mais detalhes, consulte Gerenciamento de índices.
## Exemplo de saída CollStats
O exemplo a seguir mostra uma `collStats` saída típica com métricas de coleta e armazenamento de lixo:
```
{
"ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
"MVCCIdStats" : {
"MVCCIdScale" : 0.03
},
"gcRuntimeStats" : {
"numRuns" : 1,
"historicalAvgRuntime" : 3295,
"historicalMaxRuntime" : 3295,
"lastRuntime" : 3295,
"lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
},
"documentFragmentStats" : {
"totalDocFragmentsCount" : 45000000,
"deadDocFragmentsCount" : 2250000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 98304000,
"storageSegmentBase" : {
"totalDocFragmentsCount" : 30000000,
"deadDocFragmentsCount" : 1500000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 65536000
},
"storageSegmentExtended" : {
"totalDocFragmentsCount" : 15000000,
"deadDocFragmentsCount" : 750000,
"deadDocFragmentsPercent" : 5.0,
"deadDocFragmentBytes" : 32768000
}
},
"collScans" : 14,
"count" : 30000000,
"size" : 1320000000,
"avgObjSize" : 44,
"storageSize" : 6461497344,
"storageSizeStats" : {
"storageSegmentBase" : 4307664896,
"storageSegmentExtended" : 2153832448
},
"capped" : false,
"nindexes" : 2,
"totalIndexSize" : 9649553408,
"indexSizes" : {
"_id_" : 1910661120,
"c_1" : 7738892288
},
"unusedStorageSize" : {
"unusedBytes" : 4201881600,
"unusedPercent" : 65.05,
"storageSegmentBase" : {
"unusedBytes" : 2801254400,
"unusedPercent" : 65.05
},
"storageSegmentExtended" : {
"unusedBytes" : 1400627200,
"unusedPercent" : 65.05
}
},
"cacheStats" : {
"collBlksHit" : 171659016,
"collBlksRead" : 754061,
"collHitRatio" : 99.5627,
"idxBlksHit" : 692563636,
"idxBlksRead" : 1177921,
"idxHitRatio" : 99.8303
},
"idxScans" : 41823984,
"opCounter" : {
"numDocsIns" : 0,
"numDocsUpd" : 20911992,
"numDocsDel" : 0
},
"lastReset" : "2025-06-24 05:57:08.219711+00",
"ok" : 1,
"operationTime" : Timestamp(1750968826, 1)
}
```
## Perguntas frequentes
### Como faço para identificar se a coleta de resíduos não está funcionando de forma eficiente?
Monitore estes sinais de alerta que indicam coleta de resíduos ineficiente:
+ **Excessivo inchaço da coleção** — Aumento constante das `unusedStorageSize` métricas durante gravações pesadas ou exclusões em massa, especialmente com índices grandes.
+ **Alta porcentagem de fragmentos mortos** — `documentFragmentStats` mostrando `deadDocFragmentsPercent` valores consistentemente altos (acima de 10-15%).
+ **Latência de consulta reduzida — Aumento da latência** de consulta devido ao acúmulo de documentos mortos.
+ **Duração estendida do GC** — As operações de coleta de lixo demoram mais do que as médias históricas em. `gcRuntimeStats`
+ **Processamento de GC elevado** — Alto `LongestActiveGCRuntime` indicador de que o coletor de lixo não consegue atender às demandas do sistema.
### A coleta de resíduos afeta a performance do meu banco de dados?
Em condições normais, a coleta de resíduos tem um impacto mínimo na performance. No entanto, quando a coleta de resíduos atrasa, pode ser que você experimente:
+ Aumento dos custos de armazenamento de documentos mortos acumulados.
+ Desempenho de consulta mais lento devido a entradas de índice obsoletas.
+ Modo somente leitura temporário se o MVCC estiver esgotado IDs .
+ Maior uso de recursos durante execuções intensivas de coleta, especialmente em instâncias menores.
+ Eficiência reduzida em operações de segmentos de armazenamento estendidos para documentos grandes.
### Posso acionar manualmente a coleta de resíduos?
Não, a coleta de resíduos no Amazon DocumentDB não pode ser acionada manualmente. O sistema gerencia a coleta de resíduos automaticamente como parte de suas operações internas de manutenção.
### Quais alarmes devo definir como prática recomendada operacional?
Recomendamos configurar o monitoramento nos níveis de cluster e coleção para garantir a performance ideal do seu sistema do Amazon DocumentDB.
Para monitoramento em nível de cluster, comece criando um CloudWatch alarme da Amazon para a `AvailableMVCCIds` métrica com um limite de 1,3 bilhão. Isso proporciona tempo suficiente para uma ação antes que a métrica chegue a zero, momento em que seu cluster entraria no modo somente de leitura. Lembre-se de que essa métrica pode flutuar com base em seus padrões de uso específicos. Alguns clientes a veem cair abaixo de 1,3 bilhão e depois se recuperar acima de 1,5 bilhão à medida que a coleta de lixo conclui seu trabalho.
Também é importante monitorar a `LongestActiveGCRuntime` métrica por meio da Amazon CloudWatch. Essa métrica, junto com `gcRuntimeStats`, ajuda você a entender a eficiência com que a coleta de resíduos está funcionando em todo o sistema.
Para monitoramento em nível de coleção, concentre-se nessas métricas principais:
+ `MVCCIdScale`— Observe os valores crescentes que sugerem que o MVCC IDs está envelhecendo e pode precisar de atenção.
+ `gcRuntimeStats`— identifique processos de coleta de lixo que demoram muito ou se estendem por vários dias.
+ `documentFragmentStats`— Monitore `deadDocFragmentsPercent` valores — porcentagens consistentemente altas (acima de 10-15%) podem indicar que a coleta de lixo está ficando para trás.
+ `storageSizeStats`e `unusedStorageSize` — Rastreie os padrões de utilização do armazenamento e identifique coleções com espaço não utilizado significativo em qualquer segmento de armazenamento.
Coleções com operações de gravação frequentes precisam de atenção extra, pois geram mais trabalho para o coletor de resíduos. Recomendamos verificar essas métricas com mais frequência para coleções com muita atividade de gravação, para garantir que a coleta de resíduos acompanhe a sua workload.
Observe que essas recomendações de monitoramento servem como ponto de partida. À medida que você se familiariza com o comportamento do seu sistema, talvez queira ajustar esses limites para melhor corresponder aos seus padrões e requisitos de uso específicos.
### O que devo fazer se meu `AvailableMVCCIds` cair abaixo de 1,3 bilhão?
Caso sua métrica `AvailableMVCCIds` caia abaixo de 1,3 bilhão, recomendamos tomar medidas imediatas para evitar que seu cluster entre no modo somente de leitura. Recomendamos primeiramente aumentar o tamanho da sua instância para fornecer ao coletor de resíduos mais recursos computacionais. Essa é nossa principal recomendação, pois permite que seu aplicativo continue com as operações normais e, ao mesmo tempo, forneça ao coletor de lixo a energia adicional necessária para se recuperar.
Se o aumento da escala na vertical, por si só, não melhorar a situação, recomendamos considerar uma redução em suas operações de gravação. Use a `MVCCIdScale` métrica para identificar quais coleções específicas contêm MVCC mais antigos IDs que precisam de atenção. Além disso, monitore `documentFragmentStats` para identificar coleções com altas porcentagens de fragmentos mortos que possam estar contribuindo para a ineficiência da coleta de lixo.
Depois de identificar essas coleções, talvez seja necessário reduzir temporariamente as operações de gravação nelas para permitir que a coleta de resíduos se atualize. Durante o período de recuperação, recomendamos monitorar de perto a métrica `AvailableMVCCIds` para garantir que suas ações tenham o efeito desejado. Seu cluster será considerado íntegro quando o valor `AvailableMVCCIds` retornar para 1,5 bilhão ou mais.
Lembre-se de que essas etapas são medidas preventivas para ajudar seu sistema a se recuperar antes de atingir um estado crítico. Quanto mais cedo você agir tão logo veja a métrica cair abaixo de 1,3 bilhão, maior a probabilidade de evitar qualquer impacto em suas operações de gravação.