Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Solución de problemas de Amazon DocumentDB
En las siguientes secciones, se proporciona información acerca de cómo solucionar los problemas que puedan surgir al utilizar Amazon DocumentDB (compatible con MongoDB).
**Topics**
+ [Problemas de conectividad](troubleshooting.connecting.md)
+ [Índices](troubleshooting.index-creation.md)
+ [Rendimiento y utilización de recursos](user_diagnostics.md)
+ [Recopilación de elementos no utilizados](garbage-collection.md)
# Solución de problemas de conexión
¿Tiene problemas para conectarse? A continuación se muestran algunos escenarios comunes y cómo resolverlos.
**Temas**
+ [No se puede conectar a un punto de conexión de Amazon DocumentDB](#troubleshooting-connecting)
+ [Comprobación de una conexión a una instancia de Amazon DocumentDB](#troubleshooting.testing-connection)
+ [Conexión a un punto de conexión no válido](#troubleshooting.invalid-endpoint)
+ [La configuración del controlador afecta al número de conexiones](#troubleshooting.driver.config)
## No se puede conectar a un punto de conexión de Amazon DocumentDB
Al intentar conectarse a Amazon DocumentDB, el siguiente es uno de los mensajes de error más comunes que podría encontrarse.
```
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
```
Este mensaje de error normalmente significa que el cliente (el intérprete de comandos de mongo, en este ejemplo) no puede obtener acceso al punto de conexión de Amazon DocumentDB. Esto puede deberse a varios motivos:
**Topics**
+ [Conexión desde puntos de conexión públicos](#troubleshooting.cannot-connect.public-endpoints)
+ [Conexiones entre regiones](#troubleshooting.cannot-connect.different-regions)
+ [Conectarse desde diferentes Amazon VPCs](#troubleshooting.cannot-connect.different-vpcs)
+ [Conexiones entrantes en bloques del grupo de seguridad](#troubleshooting.cannot-connect.inbound-not-allowed)
+ [Problema de preferencia de lectura del controlador Java Mongo](#troubleshooting-cannot-connect-java-mongo-issue)
### Conexión desde puntos de conexión públicos
**Está intentando conectarse a un clúster de Amazon DocumentDB directamente desde un portátil o un equipo de desarrollo local.**
Se producirá un error al intentar conectarse a un clúster de Amazon DocumentDB directamente desde un dispositivo de punto de conexión público, como una laptop o una máquina de desarrollo local. Amazon DocumentDB solo está diseñado para una nube privada virtual (VPC) y actualmente no admite puntos de conexión públicos. Por lo tanto, no puede conectarse directamente a su clúster de Amazon DocumentDB desde un portátil o un entorno de desarrollo local que esté fuera de la VPC.
Para conectarse a un clúster de Amazon DocumentDB desde fuera de una VPC de Amazon, puede utilizar un túnel de SSH. Para obtener más información, consulte [Conexión a un clúster de Amazon DocumentDB desde fuera de una Amazon VPC](connect-from-outside-a-vpc.md). Asimismo, si su entorno de desarrollo se encuentra en una VPC distinta, también puede utilizar una interconexión de VPC y conectarse a su clúster de Amazon DocumentDB desde otra VPC de Amazon que esté en la misma región o en una región diferente.
### Conexiones entre regiones
**Está intentando conectarse a un clúster de Amazon DocumentDB de otra región.**
Si intenta conectarse a un clúster de Amazon DocumentDB desde una instancia de Amazon EC2 en una región distinta a la región del clúster (por ejemplo, si intenta conectarse a un clúster en región Este de EE. UU. (Norte de Virginia) (us-east-1) desde la región Oeste de EE. UU. (Oregón) (us-west-2), la conexión fallará.
Para verificar la región del clúster de Amazon DocumentDB, ejecute el siguiente comando. La región está en el punto de conexión.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].Endpoint'
```
La salida de esta operación será similar a lo que se indica a continuación.
```
[
"sample-cluster.node.us-east-1.docdb.amazonaws.com"
]
```
Para verificar la región de la instancia EC2, ejecute el siguiente comando.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].Placement.AvailabilityZone'
```
La salida de esta operación será similar a lo que se indica a continuación.
```
[
[
"us-east-1a"
]
]
```
### Conectarse desde diferentes Amazon VPCs
**Está intentando conectarse a un clúster de Amazon DocumentDB desde una VPC distinta de la VPC de Amazon en la que se ha implementado el clúster.**
Si tanto el clúster de Amazon DocumentDB como la instancia de Amazon EC2 se encuentran en la Región de AWS misma Amazon VPC, pero no en la misma, no podrá conectarse directamente a su clúster de Amazon DocumentDB a menos que esté habilitado el emparejamiento de VPC entre los dos Amazon. VPCs
Para comprobar la Amazon VPC de su instancia de Amazon DocumentDB, ejecute el siguiente comando.
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].DBSubnetGroup.VpcId'
```
Para comprobar la Amazon VPC de su instancia de Amazon EC2, ejecute el siguiente comando.
```
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].VpcId'
```
### Conexiones entrantes en bloques del grupo de seguridad
**Está intentando conectarse a un clúster de Amazon DocumentDB, pero el grupo de seguridad del clúster no admite conexiones entrantes en el puerto del clúster (el puerto predeterminado es el 27017).**
Supongamos que el clúster de Amazon DocumentDB y la instancia Amazon EC2 se encuentran en la misma región y la VPC de Amazon, y utiliza el mismo grupo de seguridad de Amazon VPC. Si no puede conectarse al clúster de Amazon DocumentDB, es probable que la causa sea que el grupo de seguridad (es decir, el firewall) del clúster no permite las conexiones entrantes en el puerto que eligió para el clúster de Amazon DocumentDB (el puerto predeterminado es el 27017).
Para verificar el puerto del clúster de Amazon DocumentDB, ejecute el siguiente comando.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[DBClusterIdentifier,Port]'
```
Para obtener el grupo de seguridad de Amazon DocumentDB de su clúster, ejecute el siguiente comando.
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[VpcSecurityGroups[*],VpcSecurityGroupId]'
```
Para comprobar las reglas de entrada del grupo de seguridad, consulte los temas siguientes de la documentación de Amazon EC2:
+ [Autorización del tráfico de entrada para sus instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/authorizing-access-to-an-instance.html)
+ [Autorización del tráfico de entrada para sus instancias de Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/authorizing-access-to-an-instance.html)
### Problema de preferencia de lectura del controlador Java Mongo
**No se respetan las preferencias de lectura del cliente y algunos clientes no pueden escribir en Amazon DocumentDB después de una conmutación por error a menos que reinicien.**
Este problema, descubierto por primera vez en Java Mongo Driver 3.7.x, se produce cuando un cliente establece una conexión con Amazon DocumentDB mediante `MongoClientSettings` y, específicamente, al encadenar el método `applyToClusterSettings`. La configuración del MongoClient clúster se puede definir mediante varios métodos diferentes, como, y. `hosts()` `requiredReplicaSetName()` `mode()`
Cuando el cliente especifica solo un host en el método `hosts()`, el modo se establece en `ClusterConnectionMode.SINGLE` lugar de `ClusterConnectionMode.MULTIPLE`. Esto hace que el cliente ignore la preferencia de lectura y solo se conecte al servidor configurado en `hosts()`. Por lo tanto, incluso si la configuración del cliente se inicializa como se muestra a continuación, todas las lecturas seguirán yendo a la principal en lugar de a la secundaria.
```
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 conmutación por error**
Con la configuración de conexión del cliente anterior, si se produce una conmutación por error y se retrasa la actualización del registro de DNS en el punto de conexión del escritor del clúster, el cliente seguirá intentando realizar escrituras en el antiguo escritor (que ahora se lee tras la conmutación por error). Esto provoca un error en el servidor (no en el principal) que el controlador de Java no gestiona adecuadamente (el problema aún se está investigando). Por lo tanto, el cliente puede quedar en mal estado hasta que se reinicie el servidor de aplicaciones, por ejemplo.
Existen dos soluciones alternativas para ello:
+ Los clientes que se conecten a Amazon DocumentDB mediante una cadena de conexión no tendrán este problema, ya que `ClusterConnectionMode` se establecerá en `MULTIPLE` al configurar la preferencia de lectura.
```
MongoClientURI mongoClientURI = new MongoClientURI("mongodb://usr:pass:cluster-endpoint:27317/test?ssl=false&replicaSet=rs0&readpreference=secondaryPreferred");
MongoClient mongoClient = MongoClients.create(mongoClientURI.getURI());
```
O usar el constructor `MongoClientSettings` con el 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);
```
+ Establecido `ClusterConnectionMode` explícitamente en `MULTIPLE`. Esto solo es necesario cuando se usa `applyToClusterSettings` y `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);
```
## Comprobación de una conexión a una instancia de Amazon DocumentDB
Puede comprobar la conexión a un clúster mediante las herramientas habituales de Windows o de Linux.
En un terminal de Linux o Unix, puede comprobar la conexión escribiendo lo siguiente (sustituya `cluster-endpoint` por el punto de conexión y `port` por el puerto de la instancia):
```
nc -zv cluster-endpoint port
```
A continuación se muestra un ejemplo de una operación y el valor devuelto:
```
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!
```
## Conexión a un punto de conexión no válido
Si se conecta a un clúster de Amazon DocumentDB y utiliza un punto de conexión del clúster que no es válido, aparece un error similar al siguiente.
```
mongo --ssl \
--host sample-cluster.node.us-east-1.docdb.amazonaws.com:27017 \
--sslCAFile global-bundle.pem \
--username \
--password
```
El resultado tendrá este aspecto:
```
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 obtener el punto de conexión válido de un clúster, utilice el comando siguiente:
```
aws docdb describe-db-clusters \
--db-cluster-identifier sample-cluster \
--query 'DBClusters[*].[Endpoint,Port]'
```
Para obtener el punto de conexión válido de una instancia, utilice el comando siguiente:
```
aws docdb describe-db-instances \
--db-instance-identifier sample-instance \
--query 'DBInstances[*].[Endpoint.Address,Endpoint.Port]'
```
Para obtener más información, consulte [Descripción de los puntos de conexión de Amazon DocumentDB](endpoints.md).
## La configuración del controlador afecta al número de conexiones
Al utilizar el controlador de cliente para conectarse a un clúster de Amazon DocumentDB, es importante tener en cuenta el parámetro de configuración `maxPoolSize`. La configuración `maxPoolSize` determina el número máximo de conexiones que el controlador de cliente mantendrá en su grupo de conexiones.
# Índices de solución de problemas
En los temas siguientes, se explica lo que debe hacer si se produce un error durante la creación de un índice o un índice en segundo plano.
**Topics**
+ [Error al crear un índice](#troubleshooting.index-build-fails)
+ [El índice en segundo plano genera problemas de latencia y falla](#troubleshooting.background-index-build-fails)
+ [Sobrecarga del índice de base de datos](#troubleshooting-database-bloat)
## Error al crear un índice
Amazon DocumentDB utiliza el almacenamiento local de una instancia durante el proceso de creación de índices. Puede supervisar el uso de este disco mediante la **FreeLocalStorage** CloudWatch métrica (`CloudWatch -> Metrics -> DocDB -> Instance Metrics`). Cuando la generación de un índice consume todo el espacio del disco local y no finaliza, se muestra un error. Cuando migre datos a Amazon DocumentDB, conviene que cree los índices primero y, a continuación, inserte los datos. Para obtener más información sobre las estrategias de migración y la creación de índices, consulte [Migración a Amazon DocumentDB](docdb-migration.md) en la documentación de Amazon DocumentDB y la entrada de blog: [Migrar de MongoDB a Amazon DocumentDB utilizando el método sin conexión](https://aws.amazon.com/blogs/database/migrate-from-mongodb-to-amazon-documentdb-using-the-offline-method/).
Cuando cree índices en un clúster existente, si la creación del índice tarda más de lo previsto o no se realiza correctamente, le recomendamos que escale la instancia verticalmente para crear el índice y que, una vez creado, la reduzca verticalmente. Amazon DocumentDB le permite escalar rápidamente los tamaños de las instancias en cuestión de minutos utilizando Consola de administración de AWS o. AWS CLI Para obtener más información, consulte [Administración de clases de instancias](db-instance-classes.md). Dado que los precios de las instancias se calculan por segundos, solo pagará por los segundos en que esté utilizando los recursos.
## El índice en segundo plano genera problemas de latencia y falla
Las compilaciones de índices en segundo plano en Amazon DocumentDB no se inician hasta que todas las consultas de la instancia principal que se iniciaron antes de que se iniciara la creación del índice terminen de ejecutarse. Si hay una consulta de larga duración, las compilaciones de índices en segundo plano se bloquearán hasta que finalice la consulta y, por lo tanto, pueden tardar más de lo esperado en completarse. Esto es válido incluso si las colecciones están vacías.
Las compilaciones de índices en primer plano no muestran el mismo comportamiento de bloqueo. En cambio, las compilaciones de índices en primer plano controlan exclusivamente la colección hasta que se complete la creación del índice. Por lo tanto, para crear índices en una colección vacía y evitar el bloqueo de consultas de larga duración, le sugerimos que utilice compilaciones de índices en primer plano.
**nota**
Amazon DocumentDB solo permite una operación de creación de índice en segundo plano en una colección al mismo tiempo. Si se producen operaciones de DDL (Lenguaje de definición de datos) como `createIndex()` o `dropIndex()` en la misma colección durante la operación de creación de un índice en segundo plano, esta operación producirá un error.
## Sobrecarga del índice de base de datos
Amazon DocumentDB utiliza el control de concurrencia multiversión (MVCC) para gestionar las transacciones simultáneas. Cuando los documentos se eliminan o actualizan, sus versiones anteriores permanecen en las colecciones e índices como versiones «inactivas». El proceso de recopilación de elementos no utilizados recupera automáticamente el espacio de estas versiones inactivas para futuras operaciones.
La sobrecarga de índices se produce cuando el tamaño de los índices de una colección aumenta debido a la acumulación de índices inactivos u obsoletos o a la fragmentación de las páginas. El porcentaje informado representa la cantidad de espacio de índice que pueden utilizar las entradas de índice futuras. Esta sobrecarga consume espacio tanto en la memoria caché como en el almacenamiento del búfer. Si desea eliminar la sobrecarga, tendrá que recopilar los índices.
**Example Ejemplo**
Ejecute el siguiente comando para determinar el almacenamiento no utilizado del índice:
```
db.coll.aggregate({$indexStats:{}});
```
El resultado tendrá un aspecto parecido al siguiente:
```
{
"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
}
}
```
Puede reconstruir los índices sin tiempo de inactividad mediante el comando `reIndex`, que requiere escanear toda la colección. Consulte [Mantenimiento de índices mediante `reIndex`](managing-indexes.md#reIndex).
# Solución de problemas de rendimiento y utilización de recursos
En esta sección se proporcionan preguntas y soluciones para los problemas de diagnóstico frecuentes en las implementaciones de Amazon DocumentDB. Los ejemplos que se proporcionan utilizan el *intérprete de comandos de mongo* y se limitan a una instancia individual. Para encontrar un punto de conexión de instancia, consulte [Descripción de los puntos de conexión de Amazon DocumentDB](endpoints.md).
**Topics**
+ [¿Cómo determino el número de operaciones de inserción, actualización y eliminación realizadas en mi colección a través de la API de Mongo?](#user-diag-performed-operations)
+ [¿Cómo analizo el rendimiento de la memoria caché?](#user-diag-cache-perf)
+ [¿Cómo puedo encontrar y terminar las consultas que tardan mucho en ejecutarse o se bloquean?](#user_diagnostics-query_terminating)
+ [¿Cómo puedo ver un plan de consulta y optimizar una consulta?](#user_diagnostics-query_plan)
+ [¿Cómo puedo ver un plan de consultas en clústeres elásticos?](#user-diagnostics-ec-query-plan)
+ [¿Cómo puedo ver todas las operaciones en ejecución en una instancia?](#user_diagnostics-list_queries)
+ [¿Cómo sé cuándo una consulta está avanzando?](#user_diagnostics-query_progressing)
+ [¿Cómo determino por qué de repente un sistema se ejecuta lentamente?](#user_diagnostics-speed_change)
+ [¿Cómo determino la causa del uso elevado de la CPU en una o varias instancias de clúster?](#user_diagnostics-cpu_utilization)
+ [¿Cómo determino los cursores abiertos en una instancia?](#user_diagnostics-open_cursors)
+ [¿Cómo determino la versión actual del motor de Amazon DocumentDB?](#user_diagnostics-engine_version)
+ [¿Cómo analizo el uso de los índices e identifico los índices no utilizados?](#user-diag-index-usage)
+ [¿Cómo identifico los índices que faltan?](#user_diagnostics-identify_missing_indexes)
+ [¿Cómo determino la sobrecarga de colecciones de bases de datos?](#performance-collection-bloat)
+ [Resumen de consultas útiles](#user_diagnostics-useful_queries)
## ¿Cómo determino el número de operaciones de inserción, actualización y eliminación realizadas en mi colección a través de la API de Mongo?
Para ver el número de operaciones de inserción, actualización y eliminación realizadas en una colección determinada, ejecute el siguiente comando en esa colección:
```
db.collection.stats()
```
La salida de este comando describe lo siguiente en su campo `opCounters`:
+ **numDocsIns**- El número de documentos insertados en esta colección. Incluye los documentos insertados mediante los comandos `insert` y `insertMany`, así como los documentos insertados mediante actualizar o insertar.
+ **numDocsUpd**- El número de documentos actualizados en esta colección. Incluye los documentos actualizados mediante los comandos `update` y `findAndModify`.
+ **numDocsDel**- El número de documentos eliminados de esta colección. Incluye los documentos eliminados mediante los comandos `deleteOne`, `deleteMany`, `remove` y `findAndModify`.
+ **lastReset**: hora a la que se restablecieron estos contadores por última vez. Las estadísticas proporcionadas por este comando se restablecen starting/stopping al agrupar o escalar up/down la instancia.
A continuación, se muestra una salida de ejemplo de ejecución de `db.collection.stats()`.
```
{
"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)
}
```
Este comando de estadística debe usarse al ver los contadores específicos de la colección para las operaciones de inserción, actualización y eliminación a través de la API de Mongo. Otra forma de ver los contadores de operaciones específicas de una colección es habilitar la auditoría de DML. Se puede ver en [Supervisión de Amazon DocumentDB con CloudWatch](cloud_watch.md) el número de operaciones de inserción, actualización y eliminación en todas las colecciones durante intervalos de un minuto.
## ¿Cómo analizo el rendimiento de la memoria caché?
El análisis del rendimiento de la memoria caché puede proporcionar información sobre la eficiencia de la recuperación de datos y el rendimiento del sistema, y se basa en la cantidad de datos que se leen del disco en comparación con la memoria caché. Proporcionamos estadísticas de la memoria caché sobre el número de visitas a la memoria caché (datos leídos de la memoria caché) y pérdidas de memoria caché (datos que no se encuentran en la memoria caché y se leen en el disco) para obtener información sobre el rendimiento de la memoria caché. Las estadísticas de la memoria caché de una colección específica se pueden encontrar ejecutando el siguiente comando en esa colección:
```
db.collection.stats()
```
Los valores del campo `cacheStats` del resultado de este comando proporcionan las estadísticas de la memoria caché de la colección, así como las estadísticas de la memoria caché totales de los índices creados en la colección. Estas estadísticas se muestran a continuación:
+ **`collBlksHit`**: el número de bloques leídos de la memoria caché durante las operaciones de esta colección.
+ **`collBlksRead`**: el número de bloques leídos del disco (pérdidas de memoria caché) durante las operaciones de esta colección.
+ **`collHitRatio`**: la proporción de aciertos de la memoria caché de esta colección (`100 * [collBlksHit / (collBlksHit + collBlksRead)]`).
+ **`idxBlksHit`**: el número de bloques leídos de la memoria caché para cualquier índice creado en esta colección.
+ **`idxBlksRead`**: el número de bloques leídos del disco (pérdidas de memoria caché) para cualquier índice creado en esta colección.
+ **`idxHitRatio`**: la proporción de aciertos de la memoria caché creados en esta colección (`100 * [idxBlksHit / (idxBlksHit + idxBlksRead)]`).
+ **`lastReset`**: hora a la que se restablecieron estas estadísticas por última vez. Las estadísticas que proporciona `db.collection.stats()` se restablecen starting/stopping al agrupar o escalar up/down la instancia.
También se puede encontrar un desglose de los campos `idxBlksHit` y `idxBlksRead` de cada índice mediante el comando `indexStats`. Puede encontrar las estadísticas de memoria caché específicas del índice ejecutando el siguiente comando:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
Para cada índice, se encuentran las siguientes estadísticas de memoria caché en el campo `cacheStats`:
+ **`blksHit`**: el número de bloques leídos de la memoria caché para este índice.
+ **`blksRead`**: el número de bloques leídos del disco para este índice.
+ **`blksHitRatio`**: la proporción de aciertos de la memoria caché redondeada a cuatro decimales, calculada mediante `100 * [blksHit / (blksHit + blksRead)]`.
## ¿Cómo puedo encontrar y terminar las consultas que tardan mucho en ejecutarse o se bloquean?
Es posible que las consultas del usuario se ejecuten lentamente debido a que el plan de consultas es inadecuado o a que se bloquean debido a la contención de recursos.
Para buscar consultas de ejecución prolongada que se ralenticen a causa de un plan de consultas inadecuado o consultas que se bloquean debido a la contención de recursos, utilice el comando `currentOp`. Puede filtrar el comando para acotar la lista de las consultas relevantes que deben terminarse. Debe tener asociado `opid` a la consulta de ejecución prolongada para poder terminarla.
En la siguiente consulta, se utiliza el comando `currentOp` para ver todas las consultas que están bloqueadas o que se llevan ejecutando durante más 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: {}
});
```
A continuación, puede limitar la consulta para encontrar el `opid` de una consulta que lleva ejecutándose durante más de 10 segundos y terminarla.
**Para encontrar y terminar una consulta que lleva ejecutándose durante más de 10 segundos**
1. Busque el `opid` de la consulta.
```
db.adminCommand({
aggregate: 1,
pipeline: [
{$currentOp: {}},
{$match:
{$or:
[{secs_running: {$gt: 10}},
{WaitState: {$exists: true}}]}}],
cursor: {}
});
```
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 24646,
"secs_running" : 12
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
1. Termine la consulta con la operación `killOp`.
```
db.adminCommand({killOp: 1, op: 24646});
```
## ¿Cómo puedo ver un plan de consulta y optimizar una consulta?
Si una consulta se ejecuta lentamente, podría deberse a que la ejecución de la consulta requiere un examen completo de la colección para elegir los documentos pertinentes. A veces, la creación de los índices adecuados permite que la consulta se ejecute con mayor rapidez. Para detectar este escenario y decidir en qué campos se deben crear los índices, utilice el comando `explain`.
**nota**
Amazon DocumentDB emula la API MongoDB 3.6 en un motor de base de datos personalizada específicamente que utiliza un sistema de almacenamiento distribuido, tolerante a fallos y de recuperación automática. Como resultado, los planes de consulta y la salida de `explain()` pueden diferir entre Amazon DocumentDB y MongoDB. Los clientes que deseen controlar su plan de consulta pueden utilizar el operador `$hint` para aplicar la selección de un índice preferido.
Ejecute la consulta que desee mejorarse en el comando `explain` del modo siguiente.
```
db.runCommand({explain: {}})
```
A continuación se muestra un ejemplo de operación.
```
db.runCommand({explain:{
aggregate: "sample-document",
pipeline: [{$match: {x: {$eq: 1}}}],
cursor: {batchSize: 1}}
});
```
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "COLLSCAN"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
El resultado anterior indica que la etapa `$match` requiere examinar todas las colecciones y comprobar si el campo `"x"` de cada documento es igual a 1. Si hay muchos documentos en la colección, el examen de la consulta (y, por tanto, el rendimiento general de la consulta) es muy lento. Por consiguiente, la presencia de `"COLLSCAN"` en el resultado del comando `explain` indica que el rendimiento de la consulta se puede mejorar creando los índices adecuados.
En este ejemplo, la consulta comprueba si el campo `"x"` es igual a 1 en todos los documentos. Por tanto, la creación de un índice en el campo `"x"` permite que la consulta evite el examen completo de la colección y utilice el índice para devolver los documentos pertinentes antes.
Después de crear un índice en el campo `"x"`, el resultado de `explain` es el siguiente.
```
{
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "db.test",
"winningPlan" : {
"stage" : "IXSCAN",
"indexName" : "x_1",
"direction" : "forward"
}
},
"serverInfo" : {
"host" : "...",
"port" : ...,
"version" : "..."
},
"ok" : 1
}
```
La creación de un índice en el campo `"x"` permite que la etapa `$match` utilice un análisis de índices para reducir el número de documentos en los que debe evaluarse el predicado `"x = 1"`.
En colecciones pequeñas, el procesador de consultas de Amazon DocumentDB puede optar por no utilizar un índice si las ventajas para el rendimiento son insignificantes.
## ¿Cómo puedo ver un plan de consultas en clústeres elásticos?
Para examinar un plan de consultas en clústeres elásticos, utilice el comando `explain`. A continuación, se muestra un ejemplo de operación `explain` en una consulta de búsqueda dirigida a una colección con partición:
```
db.runCommand(
{
explain: { find: "cities", filter: {"name": "Seoul"}}
}
)
```
**nota**
Amazon DocumentDB emula MongoDB en un motor de base de datos personalizada. Como resultado, los planes de consulta y la salida de `explain()` pueden diferir entre Amazon DocumentDB y MongoDB. Los clientes que deseen controlar su plan de consulta pueden utilizar el operador `$hint` para aplicar la selección de un índice preferido.
La salida de esta operación será similar a lo que se indica a continuación (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)
}
```
El resultado anterior muestra el plan de consulta para la consulta `find` en un clúster de tres particiones. Cada partición tiene varias particiones de datos que pueden tener diferentes etapas de entrada. En este ejemplo, se ejecuta un “COLLSCAN” (un escaneo de colecciones) en todas las particiones antes de fusionar los resultados en la etapa “PARTITION\$1MERGE” de cada partición. A continuación, los resultados de las particiones se combinan en la etapa “SHARD\$1MERGE” antes de enviarlos de vuelta al cliente.
## ¿Cómo puedo ver todas las operaciones en ejecución en una instancia?
Como un usuario o usuario principal, a menudo desea ver una lista de todas las operaciones que se están ejecutando actualmente en una instancia con fines de diagnóstico y para solucionar problemas. (Para obtener información acerca de cómo administrar los usuarios, consulte [Administración de usuarios de Amazon DocumentDB](security.managing-users.md)).
Con el intérprete de comandos de `mongo`, puede utilizar la siguiente consulta para ver una lista de todas las operaciones en ejecución en una instancia de Amazon DocumentDB.
```
db.adminCommand({currentOp: 1, $all: 1});
```
La consulta devuelve la lista completa de todas las consultas del usuario y las tareas internas del sistema que se están realizando actualmente en la instancia.
La salida de esta operación será similar a lo que se indica a continuación (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
}
```
Los siguientes valores son válidos para el campo `"desc"`:
+ **INTERNAL**: tareas internas del sistema, como tareas de limpieza del cursor o limpieza de usuarios obsoletos.
+ **TTLMonitor**: el hilo de supervisión de tiempo de vida (TTL). Su estado de funcionamiento se refleja en el campo `"active"`.
+ **GARBAGE\$1COLLECTION**: el subproceso del recolector de elementos no utilizados interno.
+ **CONN**: la consulta del usuario.
+ **CURSOR**: la operación consiste en un cursor inactivo que espera a que el usuario llame al comando “GetMore” para obtener el siguiente lote de resultados. En este estado, el cursor consume memoria, pero no consume capacidad de cálculo.
El resultado anterior también muestra todas las consultas del usuario que se ejecutan en el sistema. Cada consulta del usuario se ejecuta en el contexto de una base de datos y una colección. La unión de las dos se denomina *espacio de nombres*. El espacio de nombres de cada consulta del usuario está disponible en el campo `"ns"`.
A veces, es necesario ver una lista de todas las consultas del usuario que se están ejecutando en un determinado espacio de nombres. Por tanto, el resultado anterior debe filtrarse en el campo `"ns"`. A continuación, se muestra una consulta de ejemplo para conseguir el resultado que se va a filtrar. La consulta muestra todas las consultas del usuario que se están ejecutando actualmente en la base de datos `"db"` y la colección `"test"` (es decir, el espacio de nombres `"db.test"`).
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$match: {ns: {$eq: "db.test"}}}],
cursor: {}
});
```
Como usuario principal del sistema, puede ver las consultas de todos los usuarios y también todas las tareas internas del sistema. Los demás usuarios solo pueden ver sus consultas respectivas.
Si el número total de consultas y tareas internas del sistema supera el tamaño del cursor batch predeterminado, el intérprete de comandos de `mongo` genera automáticamente un objeto de iteración `'it'` para ver el resto de los resultados. Siga ejecutando el comando `'it'` hasta que se hayan agotado todos los resultados.
## ¿Cómo sé cuándo una consulta está avanzando?
Es posible que las consultas del usuario se ejecuten lentamente debido a que el plan de consultas es inadecuado o a que se bloquean debido a la contención de recursos. La depuración de estas consultas es un proceso de varios pasos en el que puede ser necesario realizar el mismo paso varias veces.
El primer paso de la depuración es mostrar todas las consultas que tardan mucho tiempo en ejecutarse o que se bloquean. La siguiente consulta muestra todas las consultas del usuario que se han ejecutado durante más de 10 segundos o que están esperando 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 la consulta anterior de forma periódica para determinar si la lista de consultas cambia e identificar la consulta de ejecución prolongada o las consultas bloqueadas.
Si el documento de salida de la consulta en cuestión tiene un campo `WaitState`, indica que la contención de recursos es la razón por la que la consulta tarda mucho en ejecutarse o se bloquea. La contención de recursos puede deberse a operaciones de E/S, tareas internas del sistema u otras consultas del usuario.
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
```
{
"waitedMS" : NumberLong(0),
"cursor" : {
"firstBatch" : [
{
"opid" : 201,
"command" : {
"aggregate" : ...
},
"secs_running" : 208,
"WaitState" : "IO"
}
],
"id" : NumberLong(0),
"ns" : "admin.$cmd"
},
"ok" : 1
}
```
Las operaciones de E/S pueden producir un cuello de botella si se ejecutan muchas consultas en diferentes colecciones al mismo tiempo en la misma instancia o si la instancia es demasiado pequeña para el conjunto de datos en el que se está ejecutando la consulta. Si las consultas son consultas de solo lectura, puede mitigar la situación anterior separando las consultas de cada colección en réplicas diferentes. En las actualizaciones simultáneas en diferentes colecciones o cuando el tamaño de la instancia es demasiado pequeño para el conjunto de datos, puede mitigarla ampliando la instancia.
Si la contención de recursos se debe a otras consultas del usuario, el campo `"blockedOn"` del documento de salida contendrá el `"opid"` de la consulta que afecta a esta consulta. Mediante el `"opid"`, siga la cadena de campos `"WaitState"` y `"blockedOn"` de todas las consultas para encontrar la consulta de la parte superior de la cadena.
Si la tarea de la parte superior de la cadena es una tarea interna, la única forma de mitigar este problema sería finalizar la consulta y volver a ejecutarla más adelante.
A continuación, se muestra un resultado de ejemplo en el que la consulta de búsqueda está bloqueada en un bloqueo de la colección propiedad de otra tarea.
```
{
"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
}
```
Si `"WaitState"` tiene los valores `"Latch"`, `"SystemLock"`, `"BufferLock"`, `"BackgroundActivity"` o `"Other"`, la contención de recursos se debe a tareas internas del sistema. Si la situación continúa durante mucho tiempo, la única forma de mitigar este problema sería finalizar la consulta y volver a ejecutarla más adelante.
## ¿Cómo determino por qué de repente un sistema se ejecuta lentamente?
A continuación, se indican algunos motivos frecuentes de la ralentización del sistema:
+ Contención excesiva de recursos entre consultas simultáneas
+ El número de consultas simultáneas activas aumenta con el tiempo
+ Tareas internas del sistema como `"GARBAGE_COLLECTION"`
Para monitorizar el uso del sistema a lo largo del tiempo, ejecute la siguiente consulta `"currentOp"` periódicamente y envíe los resultados a un almacén externo. La consulta cuenta la cantidad de consultas y operaciones en cada espacio de nombres del sistema. A continuación, puede analizar los resultados de uso del sistema para conocer la carga del sistema y tomar las medidas adecuadas.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
Esta consulta devuelve la suma de todas las consultas que se ejecutan en cada espacio de nombres, todas las tareas internas del sistema y el número único de estados de espera (si hay alguno) por espacio de nombres.
La salida de esta operación será similar a lo que se indica a continuación (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
}
```
En el resultado anterior, hay dos consultas de usuario en el espacio de nombres `"db.test"` que están bloqueadas en el bloqueo de colección: una consulta en el espacio de nombres `"admin.$cmd"` y una tarea interna `"TTLMonitor"`.
Si el resultado indica muchas consultas con estados de espera de bloqueo, consulte [¿Cómo puedo encontrar y terminar las consultas que tardan mucho en ejecutarse o se bloquean?](#user_diagnostics-query_terminating)
## ¿Cómo determino la causa del uso elevado de la CPU en una o varias instancias de clúster?
Las secciones siguientes pueden ayudarle a identificar la causa del uso elevado de la CPU en una instancia. Los resultados pueden variar en función de la carga de trabajo.
+ Para determinar por qué una instancia de repente se ejecuta lentamente, consulte [¿Cómo determino por qué de repente un sistema se ejecuta lentamente?](#user_diagnostics-speed_change)
+ Para identificar y terminar consultas de ejecución largas en una instancia determinada, consulte [¿Cómo puedo encontrar y terminar las consultas que tardan mucho en ejecutarse o se bloquean?](#user_diagnostics-query_terminating)
+ Para saber si una consulta avanza, consulte [¿Cómo sé cuándo una consulta está avanzando?](#user_diagnostics-query_progressing)
+ Para determinar por qué una consulta tarda mucho tiempo en ejecutarse, consulte [¿Cómo puedo ver un plan de consulta y optimizar una consulta?](#user_diagnostics-query_plan)
+ Para realizar un seguimiento de las consultas de ejecución prolongada con el tiempo, consulte [Creación de perfiles de operaciones en Amazon DocumentDB](profiling.md).
En función del motivo del uso elevado de la CPU en la instancia, puede resultar útil realizar una o varias de las siguientes acciones.
+ Si la instancia principal presenta un uso elevado de la CPU, pero las instancias de réplica no, considere la posibilidad de distribuir el tráfico de lectura entre las réplicas a través de la configuración de preferencia de lectura del cliente (por ejemplo, `secondaryPreferred`). Para obtener más información, consulte [Conexión a Amazon DocumentDB como conjunto de réplicas](connect-to-replica-set.md).
Si se utilizan réplicas para las lecturas, se puede aprovechar mejor los recursos del clúster permitiendo que la instancia principal procese más tráfico de escritura. Las lecturas de las réplicas presentan consistencia final.
+ Si el uso elevado de la CPU se debe a la carga de trabajo de escritura, cambiar el tamaño de las instancias del clúster a un tipo de instancia mayor aumenta el número de núcleos de la CPU disponibles para atender la carga de trabajo. Para obtener más información, consulte [instancias](what-is.md#what-is-db-instances) y [Especificaciones de clases de instancias](db-instance-classes.md#db-instance-class-specs).
+ Si todas las instancias del clúster presentan un uso elevado de la CPU y la carga de trabajo utiliza réplicas para las lecturas, añadir más réplicas al clúster aumenta los recursos disponibles para el tráfico de lectura. Para obtener más información, consulte [Agregación de una instancia de Amazon DocumentDB a un clúster](db-instance-add.md).
## ¿Cómo determino los cursores abiertos en una instancia?
Cuando está conectado a una instancia Amazon DocumentDB, puede utilizar el comando `db.runCommand("listCursors")` para enumerar los cursores abiertos en esa instancia. Hay un límite de hasta 4560 cursores activos abiertos en un momento dado en una instancia determinada de Amazon DocumentDB, según el tipo de instancia. Por lo general, se recomienda cerrar cursores que ya no están en uso porque los cursores utilizan recursos en una instancia y tienen un límite superior. Consulte en [Cuotas y límites de Amazon DocumentDB](limits.md) los límites específicos.
```
db.runCommand("listCursors")
```
## ¿Cómo determino la versión actual del motor de Amazon DocumentDB?
Para determinar la versión actual del motor de Amazon DocumentDB, ejecute el siguiente comando.
```
db.runCommand({getEngineVersion: 1})
```
La salida de esta operación será similar a lo que se indica a continuación (formato JSON).
```
{ "engineVersion" : "2.x.x", "ok" : 1 }
```
**nota**
La versión de motor de Amazon DocumentDB 3.6 es 1.x.x, la versión de motor de Amazon DocumentDB 4.0 es 2.x.x, la versión de motor de Amazon DocumentDB 5.0 es 3.x.x y la versión de motor de Amazon DocumentDB 8.0 es 4.x.x.
## ¿Cómo analizo el uso de los índices e identifico los índices no utilizados?
Para identificar los índices de una colección determinada, ejecute el siguiente comando:
```
db.collection.getIndexes()
```
Para analizar cuántos índices se utilizan durante las operaciones realizadas en las colecciones, se pueden utilizar los comandos `collStats` y `indexStats`. Para ver el número total de escaneos realizados con índices (escaneos de índices) en comparación con el número de escaneos realizados sin un índice (escaneos de colecciones), ejecute el siguiente comando:
```
db.collection.stats()
```
El resultado de este comando incluye los valores que se muestran a continuación:
+ **`idxScans`**: el número de escaneos realizados en esta colección mediante un índice.
+ **`collScans`**: el número de escaneos realizados en esta colección sin un índice. Estos escaneos habrían implicado revisar los documentos de la colección uno por uno.
+ **`lastReset`**: hora a la que se restablecieron estos contadores por última vez. Las estadísticas proporcionadas por este comando se restablecen al agrupar o escalar la instancia. starting/stopping up/down
En el resultado del siguiente comando se muestra un desglose del uso de cada índice. Se recomienda identificar y eliminar periódicamente los índices que no se utilizan para mejorar el rendimiento y reducir los costes, ya que de esta forma se eliminan los gastos de cómputo y almacenamiento innecesarios y I/Os se utilizan para mantener los índices.
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
El resultado de este comando proporciona los siguientes valores para cada índice creado en la colección:
+ **`ops`**: el número de operaciones que utilizaron el índice. Si la carga de trabajo se ha ejecutado durante un tiempo suficientemente largo y está seguro de que se encuentra en un estado estable, un valor `ops` de cero indicaría que el índice no se utiliza en absoluto.
+ **`numDocsRead`**: el número de documentos leídos durante las operaciones que utilizan este índice.
+ **`since`**: el tiempo transcurrido desde que Amazon DocumentDB comenzó a recopilar estadísticas sobre el uso del índice, que suele ser el valor transcurrido desde la última acción de reinicio o mantenimiento de la base de datos.
+ **`size`**: tamaño de este archivo en bytes.
El siguiente ejemplo es una muestra del resultado de ejecutar el comando anterior:
```
{
"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 el tamaño del índice general de una colección, ejecute el siguiente comando:
```
db.collection.stats()
```
Para eliminar un índice no utilizado, ejecute el siguiente comando:
```
db.collection.dropIndex("indexName")
```
## ¿Cómo identifico los índices que faltan?
Puede utilizar el [generador de perfiles de Amazon DocumentDB para registrar consultas lentas](https://docs.aws.amazon.com//documentdb/latest/developerguide/profiling.html). Una consulta que aparece repetidamente en el registro de consultas lentas puede indicar que se requiere un índice adicional para mejorar el rendimiento de esa consulta.
Para identificar opciones de índices útiles, puede buscar consultas de larga duración que tengan una o más etapas que realicen al menos una etapa `COLLSCAN`, lo que significa que la etapa de consulta tiene que leer todos los documentos de la colección para proporcionar una respuesta a la consulta.
En el ejemplo siguiente se muestra una consulta en una colección de viajes en taxi que se ejecutaron en una colección grande.
```
db.rides.count({"fare.totalAmount":{$gt:10.0}}))
```
Para ejecutar este ejemplo, la consulta tuvo que realizar un análisis de la colección (es decir, leer cada documento de la colección), ya que no hay ningún índice en el campo `fare.totalAmount`. La salida del generador de perfiles de Amazon DocumentDB para esta consulta es similar a la siguiente:
```
{
...
"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 la consulta de este ejemplo, crearía un índice en `fare.totalAmount`, como se muestra a continuación.
```
db.rides.createIndex( {"fare.totalAmount": 1}, {background: true} )
```
**nota**
Los índices creados en el primer caso (es decir, cuando la opción `{background:true}` no se proporciona al crear el índice) utilizan un bloqueo de escritura exclusivo, lo que impide que las aplicaciones escriban datos en la colección hasta que se completa la creación del índice. Tenga en cuenta este impacto potencial al crear índices en clústeres de producción. Al crear índices, recomendamos configurar `{background:true}`.
En general, le convendrá crear índices en campos que tengan una cardinalidad alta (por ejemplo, un gran número de valores únicos). Crear un índice en un campo con cardinalidad baja puede producir un índice grande que no se utilice. El optimizador de consultas de Amazon DocumentDB tiene en cuenta el tamaño general de la colección y la selectividad de los índices al crear un plan de consulta. Hay momentos en los que verá que el procesador de consultas selecciona una etapa `COLLSCAN` incluso cuando un índice está presente. Esto sucede cuando el procesador de consultas estima que la utilización del índice no ofrecerá una ventaja de rendimiento sobre el análisis de toda la colección. Si desea obligar a que el procesador de consultas utilice un índice en particular, puede utilizar el operador `hint()` como se muestra a continuación.
```
db.collection.find().hint("indexName")
```
## ¿Cómo determino la sobrecarga de colecciones de bases de datos?
La sobrecarga de colecciones se produce cuando el tamaño de una colección aumenta debido a la acumulación de documentos inactivos u obsoletos o a la fragmentación de las páginas de la base de datos. El porcentaje informado representa la cantidad de espacio de documento que pueden utilizar documentos futuros. Esta sobrecarga consume espacio tanto en la memoria caché como en el almacenamiento del búfer. Para eliminar la sobrecarga, las colecciones deben volver a cargarse mediante dump/restore un bucle de migración y una conmutación durante un período de mantenimiento.
**Example Ejemplo**
Ejecute el siguiente comando para determinar el almacenamiento no utilizado de la colección:
```
db.runCommand({collStats:'coll'})
```
El resultado tendrá un aspecto parecido al siguiente:
```
{
"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)
}
```
## Resumen de consultas útiles
Las siguientes consultas pueden resultar útiles para monitorizar el rendimiento y el uso de recursos en Amazon DocumentDB..
+ Utilice el siguiente comando para ver las estadísticas de una colección específica, incluidos los contadores de operaciones, las estadísticas de memoria caché, las estadísticas de acceso y las estadísticas de tamaño:
```
db.collection.stats()
```
+ Utilice el siguiente comando para ver las estadísticas de cada índice creado en una colección, incluido el tamaño del índice, las estadísticas de caché específicas del índice y las estadísticas de uso del índice:
```
db.collection.aggregate([{$indexStats:{}}]).pretty()
```
+ Utilice la siguiente consulta para ver toda la actividad.
```
db.adminCommand({currentOp: 1, $all: 1});
```
+ El código siguiente muestra una lista de todas las consultas de ejecución prolongada o bloqueadas.
```
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: {}
});
```
+ El código siguiente finaliza una consulta.
```
db.adminCommand({killOp: 1, op: });
```
+ Utilice el código siguiente para obtener una vista acumulada del estado del sistema.
```
db.adminCommand({aggregate: 1,
pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
{$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
cursor: {}
});
```
# Recopilación de elementos no utilizados en Amazon DocumentDB
Amazon DocumentDB implementa una arquitectura de base de datos de control de concurrencia multiversión (MVCC) que crea nuevas versiones de entradas de documentos e índices para cada operación de actualización. Esta arquitectura permite el aislamiento de las transacciones, evitando que los cambios de una transacción aparezcan en otra.
**Topics**
+ [Descripción de la recolección de basura en Amazon DocumentDB](#understanding-garbage-collection)
+ [Proceso de recopilación de elementos no utilizados](#garbage-collection-process)
+ [Arquitectura de almacenamiento y almacenamiento ampliado](#storage-architecture)
+ [Supervisión de recopilación de elementos no utilizados](#monitoring-garbage-collection)
+ [Ejemplo de salida de CollStats](#example-collstats-output)
+ [Preguntas frecuentes](#garbage-collection-faq)
## Descripción de la recolección de basura en Amazon DocumentDB
La recopilación de elementos no utilizados (GC) es un proceso en segundo plano automatizado que mantiene un rendimiento y una disponibilidad óptimos del sistema en Amazon DocumentDB. Al igual que muchas bases de datos modernas, la arquitectura MVCC de Amazon DocumentDB crea nuevas versiones de documentos e índices con cada actualización. Cada operación de escritura consume un identificador MVCC único de un contador finito. IDs Identifican a qué transacción pertenece una versión de un documento y si se ha confirmado o anulado. Con el tiempo, estas versiones antiguas y su MVCC IDs se acumulan y es necesario limpiarlas para evitar una degradación del rendimiento.
### Funciones de la recopilación de elementos no utilizados
El recopilador de elementos no utilizados cumple tres funciones esenciales:
+ **Recupera espacio de almacenamiento**: elimina las versiones obsoletas de documentos e índices que las consultas activas ya no necesitan, lo que libera espacio para futuras operaciones de escritura.
+ **Evita el desbordamiento de ID de MVCC: evita el desbordamiento** de ID de MVCC mediante la gestión del contador finito de MVCC. IDs Sin esta administración, el contador eventualmente alcanzaría su límite, lo que obligaría a la base de datos a pasar a un modo temporal de solo lectura hasta que se recicle. IDs
+ **Mantiene el rendimiento de las consultas**: mantiene un rendimiento óptimo de las consultas, ya que elimina las versiones inactivas de los documentos que, de otro modo, se acumularían y ralentizarían el procesamiento de las consultas.
## Proceso de recopilación de elementos no utilizados
El proceso de GC funciona por colección y puede tener varios procesos ejecutándose simultáneamente en diferentes colecciones. El proceso consta de cuatro fases secuenciales:
1. **Identificación**: el sistema identifica las versiones de documentos e índices a las que ya no hacen referencia las transacciones ni consultas activas.
1. **Carga de memoria**: los documentos antiguos y las entradas del índice se cargan en la memoria si aún no están presentes.
1. **Eliminación**: las versiones obsoletas se eliminan permanentemente para recuperar espacio de almacenamiento.
1. **Reciclaje de identificadores de MVCC**: el sistema recicla los MVCC de las versiones eliminadas para utilizarlos en IDs nuevas operaciones.
Cuando la recolección de basura termina de procesar las versiones antiguas de los documentos, elimina el MVCC IDs más antiguo del sistema. Esta limpieza es fundamental para evitar que los identificadores de los MVCC se desborden IDs, ya que reciclan los MVCC y los ponen a disposición para nuevas operaciones de escritura en todo el clúster. Sin este proceso de reciclaje, el sistema acabaría agotando su contador finito de identificadores de MVCC y pasaría a un estado de solo lectura.
### Programación de recopilación de elementos no utilizados
La recopilación de elementos no utilizados se ejecuta automáticamente en segundo plano a intervalos periódicos. La temporización y la frecuencia se ajustan dinámicamente en función de la carga del sistema, los recursos disponibles, el volumen de escritura y los niveles de consumo de los identificadores de MVCC. Cuando hay mucha actividad de escritura, el proceso de GC se ejecuta con más frecuencia para administrar el aumento del número de versiones de los documentos.
## Arquitectura de almacenamiento y almacenamiento ampliado
Amazon DocumentDB utiliza una arquitectura de almacenamiento sofisticada que separa el almacenamiento de documentos en dos segmentos distintos:
### Segmento de almacenamiento base
El segmento de almacenamiento base contiene los datos y metadatos del documento principal. Este segmento almacena:
+ Contenido del documento que se ajusta al tamaño de página estándar (8 KB).
+ Información de estructura y metadatos del documento.
+ Índices principales y sus entradas.
+ Estadísticas y configuración a nivel de colección.
### Segmento de almacenamiento extendido
El segmento de almacenamiento ampliado utiliza un almacén de objetos de documentos de gran tamaño especializado diseñado para gestionar documentos que superan el tamaño de página de almacenamiento estándar. Este segmento ofrece:
+ **Gestión eficiente de documentos de gran** tamaño: los documentos que superen el umbral de almacenamiento base se trasladan automáticamente al segmento de almacenamiento ampliado.
+ **Diseño de almacenamiento optimizado**: el segmento utiliza un formato de almacenamiento diferente, optimizado para objetos de gran tamaño, lo que reduce la fragmentación y mejora los patrones de acceso.
+ **Recolección de basura independiente**: el segmento de almacenamiento ampliado tiene su propio proceso de recolección de basura que puede ejecutarse independientemente de la limpieza del almacenamiento base.
+ **Acceso transparente**: las aplicaciones acceden a documentos grandes sin problemas sin necesidad de saber qué segmento de almacenamiento contiene los datos.
El segmento de almacenamiento ampliado es particularmente beneficioso para:
+ Colecciones con documentos que contienen matrices integradas de gran tamaño.
+ Documentos con amplias estructuras anidadas.
+ Colecciones que almacenan datos binarios o campos de texto de gran tamaño.
+ Aplicaciones con documentos de distintos tamaños, en las que algunos documentos superan considerablemente el tamaño medio.
## Supervisión de recopilación de elementos no utilizados
### Métricas de nivel de clúster
**`AvailableMVCCIds`**
+ **Ubicación** — Amazon CloudWatch
+ **Descripción**: contador que muestra el número de operaciones de escritura restantes disponibles desde un límite máximo de 1800 millones. Cuando este contador llega a cero, el clúster pasa al modo de solo lectura hasta que IDs se recupere y se recicle. El contador disminuye con cada operación de escritura y aumenta a medida que la recolección de basura recicla el MVCC antiguo. IDs
+ **Recomendación**: active una alarma cuando el valor disminuya por debajo de 1300 millones. Esta alerta temprana le permite tomar las medidas recomendadas que se describen más adelante.
**`LongestActiveGCRuntime`**
+ **Ubicación** — Amazon CloudWatch
+ **Descripción**: duración en segundos del proceso de recopilación de elementos no utilizados más prolongado. Se actualiza cada minuto y realiza un seguimiento únicamente de las operaciones activas, excluyendo los procesos que se completan en el intervalo de un minuto.
+ **Recomendación**: Compárelos con los datos `gcRuntimeStats` históricos para identificar un comportamiento anormal en la recolección de basura, como los tiempos de ejecución prolongados durante las eliminaciones masivas.
### Métricas a nivel de la colección
**`MVCCIDStats: MVCCIdScale`**
+ **Ubicación**: comando collStats de la base de datos
+ **Descripción**: mide la antigüedad del identificador de MVCC en una escala de 0 a 1, donde 1 indica la antigüedad máxima antes de que un clúster entre en estado de solo lectura. Utilice esta métrica `AvailableMVCCIds` para identificar las colecciones que contienen el MVCC más antiguo y IDs que están anticuadas en el clúster.
+ **Recomendación**: mantenga los valores por debajo de 0,3 para cada colección.
**`gcRuntimeStats`**
+ **Ubicación**: comando collStats de la base de datos
+ **Descripción**: proporciona un historial de dos meses con las métricas de recopilación de elementos no utilizados, que incluye el total de ejecuciones, la duración promedio y la duración máxima. Solo incluye las operaciones de recopilación de elementos no utilizados que duren más de cinco minutos para garantizar estadísticas significativas.
**importante**
`gcRuntimeStats``documentFragmentStats`, y el desglose de las métricas a nivel de recopilación en Amazon DocumentDB `storageSegmentBase` 8.0 y solo `storageSegmentExtended` están disponibles para Amazon DocumentDB 8.0.
**`storageSizeStats`**
+ **Ubicación**: comando collStats de la base de datos
+ **Descripción**: proporciona un desglose detallado de la utilización del almacenamiento en los diferentes segmentos de almacenamiento:
+ `storageSegmentBase`— Almacenamiento utilizado por el segmento de almacenamiento base para documentos estándar
+ `storageSegmentExtended`— Almacenamiento utilizado por el segmento de almacenamiento ampliado para documentos de gran tamaño
+ **Uso**: ayuda a identificar las colecciones con un almacenamiento de documentos de gran tamaño y a comprender los patrones de distribución del almacenamiento.
**`unusedStorageSize`** (nivel de colección)
+ **Ubicación**: comando collStats de la base de datos
+ **Descripción**: estima el espacio de almacenamiento no utilizado en una colección en función de las estadísticas muestreadas. Incluye el espacio de los documentos eliminados y de los segmentos vacíos. La métrica proporciona tanto los totales combinados como los desgloses por segmento:
+ Combinados `unusedBytes` y en `unusedPercent` todos los segmentos de almacenamiento
+ `storageSegmentBase`— Espacio no utilizado específicamente en el segmento de almacenamiento base
+ `storageSegmentExtended`— Espacio no utilizado específicamente en el segmento de almacenamiento ampliado
**`documentFragmentStats`**
+ **Ubicación**: comando collStats de la base de datos
+ **Descripción**: proporciona información detallada sobre los fragmentos de documentos y los datos inactivos de las colecciones. Los fragmentos de documentos representan las unidades de almacenamiento internas utilizadas por el motor de base de datos, y los fragmentos muertos indican datos a los que ya no se puede acceder pero que aún no se han recuperado. Esta métrica incluye:
+ `totalDocFragmentsCount`— Número total de fragmentos de documentos de la colección
+ `deadDocFragmentsCount`— Número de fragmentos que contienen datos muertos (inaccesibles)
+ `deadDocFragmentsPercent`— Porcentaje de fragmentos que contienen datos muertos
+ `deadDocFragmentBytes`— Número estimado de bytes consumidos por fragmentos de documentos muertos
+ Desglose por segmento para y `storageSegmentBase` `storageSegmentExtended`
+ **Uso**: supervise esta métrica para comprender la eficacia de la recolección de basura e identificar las recolecciones que podrían beneficiarse de las operaciones de mantenimiento. Los altos porcentajes de fragmentos muertos indican que la recolección de basura puede estar retrasándose o que la recolección se beneficiaría de una optimización.
### Métricas de nivel de índice
**`unusedStorageSize`** (nivel de índice)
+ **Ubicación**: comando IndexStats de la base de datos.
+ **Descripción**: estima el espacio de almacenamiento no utilizado en un índice en función de las estadísticas muestreadas. Incluye el espacio de las entradas de índice obsoletas y de los segmentos vacíos.
+ **Recomendación**: utilice el comando `reIndex` para compilar los índices sin tiempo de inactividad y recuperar el espacio no utilizado. Consulte Administración de índices para obtener más detalles.
## Ejemplo de salida de CollStats
El siguiente ejemplo muestra un `collStats` resultado típico con métricas de recolección y almacenamiento de basura:
```
{
"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)
}
```
## Preguntas frecuentes
### ¿Cómo puedo identificar si la recopilación de elementos no utilizados no funciona de manera eficiente?
Supervise estas señales de advertencia que indican una recopilación de elementos no utilizados ineficiente:
+ **Recolección excesiva**: `unusedStorageSize` las métricas aumentan de forma constante durante las escrituras intensivas o las eliminaciones masivas, especialmente cuando se trata de índices de gran tamaño.
+ **Alto porcentaje de fragmentos muertos**: `documentFragmentStats` muestra `deadDocFragmentsPercent` valores altos de forma constante (por encima del 10 al 15%).
+ **Latencia de consulta reducida: aumento de la latencia** de consulta debido a la acumulación de documentos inactivos.
+ **Duración extendida del GC**: las operaciones de recolección de basura tardan más que los promedios históricos. `gcRuntimeStats`
+ **Procesamiento de GC elevado**: un nivel alto `LongestActiveGCRuntime` indica que el recolector de basura no puede satisfacer las demandas del sistema.
### ¿La recopilación de elementos no utilizados afecta al rendimiento de mi base de datos?
En condiciones normales, la recopilación de elementos no utilizados tiene un impacto mínimo en el rendimiento. Sin embargo, si la recopilación de elementos no utilizados se retrasa, puede experimentar lo siguiente:
+ Aumento de los costes de almacenamiento debido a la acumulación de documentos muertos.
+ El rendimiento de las consultas es más lento debido a las entradas de índice obsoletas.
+ Modo temporal de solo lectura si los MVCC IDs están agotados.
+ Mayor uso de recursos durante las ejecuciones de recopilación intensivas, especialmente en instancias más pequeñas.
+ Reducción de la eficiencia en las operaciones del segmento de almacenamiento ampliado para documentos de gran tamaño.
### ¿Puedo activar manualmente la recopilación de elementos no utilizados?
No, la recopilación de elementos no utilizados en Amazon DocumentDB no se puede activar manualmente. El sistema administra la recopilación de elementos no utilizados automáticamente como parte de sus operaciones de mantenimiento interno.
### ¿Qué alarmas debo configurar como práctica operativa recomendada?
Recomendamos configurar la supervisión tanto a nivel de clúster como de colección para garantizar un rendimiento óptimo del sistema de Amazon DocumentDB.
Para la supervisión a nivel de clúster, comience por crear una CloudWatch alarma de Amazon para la `AvailableMVCCIds` métrica con un umbral de 1300 millones. Esto le da tiempo suficiente para tomar medidas antes de que la métrica llegue a cero, momento en el que el clúster pasará al modo de solo lectura. Ten en cuenta que esta métrica puede fluctuar en función de tus patrones de uso específicos: algunos clientes ven que cae por debajo de los 1 300 millones y luego se recupera por encima de los 1500 millones a medida que la recolección de basura termina su función.
También es importante monitorear la `LongestActiveGCRuntime` métrica a través de Amazon CloudWatch. Esta métrica, junto con `gcRuntimeStats`, le permite comprender el rendimiento de la recopilación de elementos no utilizados en todo el sistema.
Para el monitoreo a nivel de colección, concéntrate en estas métricas clave:
+ `MVCCIdScale`— Esté atento al aumento de los valores que sugieren que los MVCC IDs están envejeciendo y que podrían necesitar atención.
+ `gcRuntimeStats`— Identifique los procesos de recolección de basura que demoran inusualmente o se prolongan durante varios días.
+ `documentFragmentStats`— Supervise `deadDocFragmentsPercent` los valores: los porcentajes altos y constantes (superiores al 10-15%) pueden indicar un retraso en la recogida de basura.
+ `storageSizeStats`y `unusedStorageSize` — Realice un seguimiento de los patrones de uso del almacenamiento e identifique las colecciones con una cantidad significativa de espacio no utilizado en cualquiera de los segmentos de almacenamiento.
Las colecciones con operaciones de escritura frecuentes requieren atención especial, ya que generan más trabajo para el recopilador de elementos no utilizados. Le recomendamos que compruebe estas métricas con más frecuencia en las colecciones con mucha actividad de escritura para garantizar que la recopilación de elementos no utilizados esté a la altura de su carga de trabajo.
Tenga en cuenta que estas recomendaciones de supervisión sirven de punto de partida. A medida que se familiarice con el comportamiento de su sistema, tal vez desee ajustar estos umbrales para que se adapten mejor a sus patrones y requisitos de uso específicos.
### ¿Qué debo hacer si `AvailableMVCCIds` disminuye por debajo de los 1300 millones?
Si la métrica `AvailableMVCCIds` disminuye por debajo de los 1300 millones, le recomendamos que tome medidas inmediatas para evitar que el clúster entre en modo de solo lectura. Le recomendamos que primero amplíe el tamaño de la instancia para proporcionar más recursos informáticos al recopilador de elementos no utilizados. Esta es nuestra principal recomendación, ya que permite que su aplicación continúe con sus operaciones normales y, al mismo tiempo, le da al recolector de basura la potencia adicional que necesita para ponerse al día.
Si la ampliación por sí sola no mejora la situación, le recomendamos que considere reducir las operaciones de escritura. Utilice la `MVCCIdScale` métrica para identificar qué colecciones específicas contienen MVCC más antiguas y IDs que requieren atención. Además, supervise `documentFragmentStats` para identificar las colecciones con altos porcentajes de fragmentos muertos que puedan estar contribuyendo a la ineficiencia de la recolección de basura.
Una vez que haya identificado estas colecciones, es posible que tenga que reducir temporalmente las operaciones de escritura en ellas para permitir que la recopilación de elementos no utilizados se ponga al día. Durante el período de recuperación, le recomendamos que supervise atentamente la métrica `AvailableMVCCIds` para asegurarse de que sus acciones tengan el efecto deseado. Se considera que el clúster está en buen estado una vez que el valor `AvailableMVCCIds` vuelve a ser 1500 millones o más.
Recuerde que estos pasos son medidas preventivas para ayudar a que su sistema se recupere antes de que alcance un estado crítico. Cuanto antes tome medidas tras ver la disminución de la métrica por debajo de los 1300 millones, más probabilidades tendrá de evitar que sus operaciones de escritura se vean afectadas.