Solución de problemas de rendimiento para Databases for MongoDB

Utilice esta guía para ayudarle a identificar y resolver problemas de rendimiento en su implantación de Databases for MongoDB que se ejecuta en IBM Cloud y funciona con MongoDB.

También puedes encontrar más información sobre cómo solucionar problemas de rendimiento de la siguiente manera:

Si sus aplicaciones experimentan respuestas lentas, tiempos de espera o un rendimiento incoherente de la base de datos, tenga en cuenta los siguientes pasos e información.

Síntomas de problemas de rendimiento

Es posible que observe algunos de los siguientes síntomas que indican problemas de rendimiento:

Aumento de la latencia de las aplicaciones
Entradas lentas en el registro de consultas
Alta utilización de la CPU o de la memoria
Aumento de la latencia del disco
Retardo de réplica
Tiempos de espera de conexión

Realice los siguientes pasos para determinar la causa de los problemas:

Paso 1: Comprobar la utilización de los recursos

Inicie sesión en la consola IBM Cloud y navegue hasta su implantación MongoDB.
Revise la sección de Seguimiento para:
- Utilización de CPU
- Uso de memoria
- IOPS y latencia del disco
- Conexiones activas

En qué fijarse:

CPU constantemente por encima del 75%
Memoria siempre por encima del 80
La latencia del disco aumenta con el tiempo
Conexiones que se acercan a los límites del plan

Acciones recomendadas:

Aumente el almacenamiento o las IOPS si la latencia del disco es alta.
Revise los picos de carga de trabajo en su aplicación.

Si el uso de recursos sigue siendo elevado durante periodos prolongados, se recomienda escalar.

Paso 2: Identificar las consultas lentas

Las consultas lentas son una de las causas más comunes de la degradación del rendimiento.

Activar la creación de perfiles:

db.setProfilingLevel(1, { slowms: 100 })

Revise las operaciones lentas recientes:

db.system.profile.find().sort({ ts: -1 }).limit(20)

Analizar la ejecución de la consulta:

db.collection.find({ ... }).explain("executionStats")

En qué fijarse:

COLLSCAN (escaneo de colecciones en lugar de uso de índices)
Alto totalDocsExamined en comparación con nReturned

Acciones recomendadas:

Crear índices adecuados.
Utilizar índices compuestos para consultas de varios campos.
Asegúrese de que los conductos de agregación comienzan con $match.
Evite la paginación de gran tamaño skip().

Paso 3: Revisar el uso de la conexión

Las conexiones altas o mal gestionadas pueden afectar al rendimiento.

Comprueba las estadísticas de conexión:

db.serverStatus().connections

Acciones recomendadas:

Utilice la agrupación de conexiones en su aplicación.
Evite abrir una nueva conexión para cada solicitud.
Cierra los cursores no utilizados.

Los límites de conexión vienen determinados por su plan de despliegue.

Paso 4: Comprobar el estado de la replicación

El retraso en la replicación puede afectar al rendimiento de la lectura y a la frescura de los datos.

Comprueba el estado de la replicación:

rs.printSecondaryReplicationInfo()

Causas comunes de retraso:

Alto rendimiento de escritura
Cuellos de botella en los discos
Latencia de red

Acciones recomendadas:

Escala el rendimiento del almacenamiento.
Revisar la configuración de la preocupación por la escritura.
Escala a un plan superior si el retraso es persistente.

Paso 5: Consideraciones sobre el clúster fragmentado (si procede)

Puedes necesitar sharding en las siguientes situaciones:

El conjunto de trabajo es mayor que la RAM
IOPS de nodo único al máximo incluso después de escalar
Se requiere escalado horizontal de escritura
La recaudación supera los 1-2 TB

Para obtener más información, consulte Ajuste del rendimiento y fragmentación.

Si su despliegue utiliza sharding, ejecute:

sh.status()

Compruébalo:

Distribución desigual de los trozos
Trozos grandes
Tráfico concentrado en un único fragmento

Acciones recomendadas:

Revisar la selección de la clave de fragmentación.
Evitar el aumento monótono de las claves de los fragmentos.
Considera las claves de fragmentos con hash.

Una selección incorrecta de las claves de los fragmentos puede afectar significativamente al rendimiento a escala.

Paso 6: Después de eliminar grandes cantidades de datos

Borrar un porcentaje significativo de datos no reduce inmediatamente el uso del disco a nivel del sistema operativo.

Posibles impactos:

Fragmentación interna
Alta utilización del disco
Reducción del rendimiento

Acciones recomendadas:

Planifique cuidadosamente las operaciones de compactación.
Considere la posibilidad de volcar y restaurar en caso de fragmentación grave.
Mantenga la utilización del disco por debajo del 80-85%.

Programar adecuadamente las actividades de mantenimiento.

Paso 7: Comprobar la contención del bloqueo

La contención de bloqueos puede afectar gravemente a las operaciones simultáneas y al rendimiento global.

Comprueba las estadísticas globales de bloqueo:
```
db.serverStatus().locks
```

Compruebe si las operaciones en curso están bloqueadas:

db.currentOp({
  $or: [
    { waitingForLock: true },
    { "locks.Global": "w" }
  ]
})

Analizar el tiempo de espera de los bloqueos:
```
db.serverStatus().globalLock
```

En qué fijarse:

Valores altos de currentQueue (lectores o escritores).
Operaciones con waitingForLock: true.
Operaciones de larga duración que mantienen bloqueos.
Índices que bloquean las operaciones.

Causas comunes:

Consultas de larga duración sin índices adecuados.
Grandes operaciones de escritura.
Los índices se basan en grandes colecciones.
Comandos administrativos (compact, repairDatabase ).

Acciones recomendadas:

Detenga las operaciones de larga duración si es necesario:
```
db.killOp(opid)
```

Construir índices en segundo plano:

db.collection.createIndex({ field: 1 }, { background: true })

Divida las grandes operaciones en lotes más pequeños.
Programar las operaciones de mantenimiento en periodos de poco tráfico.
Utilizar adecuadamente la preocupación por la lectura y la preocupación por la escritura.

Paso 8: Analizar los patrones de carga de trabajo

Comprender sus patrones de carga de trabajo ayuda a identificar oportunidades de optimización.

Compruebe los contadores de operaciones:
```
db.serverStatus().opcounters
```
Analizar las operaciones a lo largo del tiempo:
```
db.serverStatus().opcountersRepl
```
Identificar las colecciones calientes:
```
db.adminCommand({ top: 1 })
```

Comprueba el ratio de lectura comparado con el ratio de escritura:

var stats = db.serverStatus().opcounters;
print("Read ratio: " + (stats.query + stats.getmore) / (stats.query + stats.getmore + stats.insert + stats.update + stats.delete));

En qué fijarse:

Operaciones desproporcionadas en colecciones específicas
Ratios elevados de lectura-escritura o escritura-lectura
Picos repentinos en los recuentos de operaciones
Patrones temporales (horas punta)

Acciones recomendadas:

Optimice primero las colecciones a las que se accede con más frecuencia.
Considere las réplicas de lectura para cargas de trabajo de lectura intensiva.
Utilice las preferencias de lectura adecuadas.
Implementar el almacenamiento en caché de los datos de lectura frecuente.
Revisar la estrategia de indexación de las colecciones calientes.
Considere la fragmentación para colecciones de escritura pesada.

Paso 9: Investigar la presión de la memoria y la eficiencia de la caché

MongoDB's WiredTiger depende en gran medida de la eficiencia de la caché.

Consulta las estadísticas de la caché WiredTiger:
```
db.serverStatus().wiredTiger.cache
```

Revisar las métricas clave:

var cache = db.serverStatus().wiredTiger.cache;
print("Cache size: " + cache["bytes currently in the cache"]);
print("Max cache size: " + cache["maximum bytes configured"]);
print("Pages read into cache: " + cache["pages read into cache"]);
print("Pages written from cache: " + cache["pages written from cache"]);
print("Cache hit ratio: " + (1 - cache["pages read into cache"] / (cache["pages read into cache"] + cache["pages requested from the cache"])));

Compruebe la presión de desalojo:

db.serverStatus().wiredTiger.cache["pages evicted by application threads"]

En qué fijarse:

El porcentaje de aciertos de la caché es inferior al 95%
Elevadas tasas de desahucio
Tamaño de la caché siempre al máximo
Hilos de aplicación que realizan desalojos

Estimación del tamaño del conjunto de trabajo:

db.serverStatus().wiredTiger.cache["tracked dirty bytes in the cache"]

Acciones recomendadas:

Escala a un plan con más memoria si la caché está constantemente llena.
Revisar y optimizar los índices (eliminar los índices no utilizados).
Limitar el tamaño del conjunto de resultados en las consultas.
Utiliza proyecciones para reducir el tamaño del documento.
Considera la posibilidad de archivar datos antiguos.
Controlar la evolución del tamaño de los grupos de trabajo.

Mejores prácticas de asignación de memoria

La caché de WiredTiger debe ser del 50% de la RAM disponible (por defecto).
Deje memoria suficiente para otros procesos.
Controla el uso de swap, que debería ser mínimo.

Paso 10: Revisar las preferencias de escritura y lectura

La configuración de las preferencias de escritura y lectura influye significativamente en el rendimiento y la coherencia.

Compruebe la preocupación de escritura actual:
```
db.getWriteConcern()
```
Compruebe la configuración del conjunto de réplicas:
```
rs.conf()
```

Escribir opciones de preocupación:

Escribir opciones de preocupación
Escribir preocupación	Durabilidad	Rendimiento	Caso de uso
`w: 1`	Bajo	Alto	Datos no críticos, alto rendimiento
`w: "majority"`	Alto	Medio	Enfoque equilibrado por defecto
`w: <number>`	Medio-Alto	Medio-Bajo	Recuento específico de réplicas
`j: true`	Máxima	Mínimo	Datos críticos que requieren sincronización con el diario

Opciones de preferencia de lectura:

Opciones de preferencia de lectura
Leer preferencia	Coherencia	Rendimiento	Caso de uso
`primary`	Máxima	Medio	Por defecto, gran coherencia
`primaryPreferred`	Alto	Medio-Alto	Paso a secundario
`secondary`	Eventual	Alto	Análisis, informes
`secondaryPreferred`	Eventual	Alto	Leer más
`nearest`	Eventual	Máxima	Latencia más baja

Marque la preferencia de lectura en su solicitud:

// Example in Node.js driver
db.collection('users').find({}).readPreference('secondary')

En qué fijarse:

Preocupaciones de escritura demasiado estrictas para datos no críticos
Uso de primary preferencia de lectura cuando la coherencia eventual es aceptable
No aprovechar los secundarios para cargas de trabajo de lectura intensiva

Acciones recomendadas:

Utilice w: 1 para escrituras no críticas de alto rendimiento.
Utilice w: "majority" para los datos importantes (por defecto).
Utilice secondary o secondaryPreferred para las consultas analíticas.
Considere nearest para aplicaciones distribuidas geográficamente.
Equilibrar los requisitos de coherencia con las necesidades de rendimiento.
Pruebe diferentes configuraciones bajo carga.

Paso 11: Supervisar el impacto de las copias de seguridad y el mantenimiento

Las operaciones de copia de seguridad y las tareas de mantenimiento pueden afectar temporalmente al rendimiento.

IBM Cloud programa de copias de seguridad

Databases for MongoDB realiza automáticamente una copia de seguridad. Compruebe su programa de copias de seguridad en la consola IBM Cloud, en Copias de seguridad.

Compruebe si hay operaciones de copia de seguridad en curso:

db.currentOp({
  $or: [
    { op: "command", "command.backup": { $exists: true } },
    { desc: /^conn/ }
  ]
})

En qué fijarse:

Disminución del rendimiento durante las ventanas de copia de seguridad
Aumento de la E/S de disco durante las copias de seguridad
Retraso en la replicación durante las copias de seguridad

Acciones recomendadas:

Supervise las métricas de rendimiento durante las copias de seguridad.
Considere la posibilidad de escalar si las copias de seguridad afectan sistemáticamente al rendimiento.
Revisar las políticas de conservación de copias de seguridad.
Planifique el aumento del uso de recursos durante las operaciones de restauración.

Buenas prácticas en las operaciones de mantenimiento

Programe las acumulaciones de índices durante los periodos de poco tráfico.
Siempre que sea posible, utilice índices de fondo.
Supervisar el retraso de la replicación durante el mantenimiento.
Pruebe primero las operaciones de mantenimiento en no producción.
Coordínese con las ventanas de mantenimiento de IBM Cloud.