Las tormentas de conexión suelen manifestarse como picos repentinos en el número de conexiones y, con frecuencia, pueden diagnosticarse erróneamente como problemas de rendimiento de la base de datos.
Esta página cubre las causas comunes y las soluciones para las tormentas de conexión y "too many connections" errores. Si necesita ayuda adicional después de revisar las siguientes secciones, póngase en contacto con el soporte técnico.
Comprobaciones de requisitos previos
Para confirmar si su implementación está experimentando una tormenta de conexiones o un problema de límite de conexiones, ejecute el serverStatus comando y verifique los siguientes indicadores:
Aumentos repentinos en
connections.currentAumentos repentinos en
connections.activeAumentando rápidamente
connections.totalCreatedAumentos en
metrics.commands.<command>.failed
También puede revisar los mensajes de registro de su implementación para detectar grandes cantidades de "Connection accepted" mensajes con un connectionCount atributo que aumenta rápidamente, o aumentos en las entradas de registro de consultas lentas.
En las implementaciones de Atlas, puede navegar hasta su clúster en la interfaz de usuario de Atlas y seleccionar Metrics, luego Connections para ver gráficos del recuento de conexiones a lo largo del tiempo.
Problemas comunes y sus soluciones
Las siguientes secciones describen las causas comunes de las crisis de conexión y cómo solucionarlas.
Configuración incorrecta del grupo de conexiones
Si se establece mucho minPoolSize maxPoolSize más bajo que, el controlador mantiene solo un número reducido de conexiones inactivas. Bajo cargas de trabajo intensas o después de un reinicio, el controlador debe abrir rápidamente muchas conexiones nuevas para alcanzar el tamaño del grupo de conexiones en funcionamiento, lo que puede provocar un pico en las conexiones nuevas.
Alta latencia del servidor o de las consultas
Si la latencia del servidor o de las consultas aumenta, las conexiones individuales permanecen activas durante más tiempo. Esto obliga al controlador a abrir conexiones adicionales para gestionar las solicitudes entrantes, lo que incrementa el número total de conexiones.
Si observa un valor connections.active elevado y una latencia de consulta alta, establezca minPoolSize en un valor más cercano a maxPoolSize en la cadena de conexión del controlador. Esto precalienta el grupo de conexiones y reduce la necesidad de abrir muchas conexiones nuevas bajo carga.
Mayor carga operativa
Un aumento repentino en el tráfico de la aplicación puede agotar el grupo de conexiones disponibles, lo que obliga al controlador a abrir nuevas conexiones rápidamente.
Si observa picos de conexión que se producen con el aumento del tráfico, considere establecer minPoolSize en un valor más cercano a maxPoolSize en la cadena de conexión del controlador. Esto garantiza que el controlador mantenga suficientes conexiones preestablecidas para gestionar los picos de tráfico sin necesidad de abrir nuevas conexiones rápidamente.
Eventos transitorios de red o reinicios de aplicaciones
Las interrupciones de la red, los reinicios progresivos o los eventos repentinos de escalado de la capa de aplicación pueden provocar que las instancias de la aplicación se reconecten simultáneamente, sobrecargando el servidor con nuevas solicitudes de conexión.
Si se producen picos de conexión durante los eventos de implementación o interrupciones de la red, considere establecer maxPoolSize para limitar el número total de conexiones que cada instancia de la aplicación puede abrir. Esto limita el impacto de los eventos de reconexión simultáneos.
Creación de MongoClient por solicitud
Si se crea una nueva MongoClient instancia en cada solicitud o invocación de función en lugar de reutilizar una única instancia compartida, cada cliente puede abrir su propio grupo de conexiones independiente hasta el límite configurado maxPoolSize de. En entornos con muchas solicitudes concurrentes o de ejecución de corta duración, esto multiplica el número total de conexiones abiertas y puede provocar congestión de conexiones.
Si observa un aumento constante en el número de conexiones que se correlaciona con el volumen de solicitudes, compruebe si su aplicación instancia una nueva instancia MongoClient por cada solicitud y considere implementar MongoClient como una única instancia compartida para todas las operaciones. Esto estabiliza el uso de conexiones y evita picos en el número de conexiones causados por la multiplicación del pool.
Grupos de enrutadores mal configurados en clústeres fragmentados
En clústeres fragmentados, cada mongos enrutador mantiene grupos de conexiones en cada fragmento. Si estos grupos no tienen el tamaño adecuado, una tormenta de conexiones en la capa de aplicación puede propagarse a la capa de fragmentos, ya que los enrutadores abren simultáneamente un gran número de conexiones internas.
Si observa tormentas de conexión originadas por procesos, considere lo mongos siguiente:
Limitar el número de grupos de
taskExecutorconexiones en cada enrutador configurandotaskExecutorPoolSizeel parámetro.Controlar el número mínimo y máximo de conexiones en cada grupo de enrutadores mediante el uso de los parámetros
ShardingTaskExecutorPoolMinSizeShardingTaskExecutorPoolMaxSizey.
Clúster de MongoDB Atlas con recursos insuficientes
Cada nivel del clúster de MongoDB Atlas impone un número máximo de conexiones entrantes simultáneas por nodo. Cuando una aplicación abre más conexiones de las que permite el nivel, el clúster puede rechazar nuevas solicitudes de conexión con el siguiente error:
connection refused because too many open connections
Si observa rechazos de conexión que ocurren con una carga mayor y no mejoran después de ajustar la configuración del grupo, verifique si connections.current está en o cerca del límite para su nivel de clúster. Para ver los límites de conexión por nivel de clúster, consulte Límites del servicio de Atlas.
Si el número de conexiones está cerca del límite del nivel del clúster, considere actualizar a un nivel superior para aumentar el límite de conexiones por nodo. Para escalar el clúster, consulte la sección Modificar un clúster.
Verificar resolución
Para confirmar que la tormenta de conexión se ha resuelto:
serverStatusVuelva a ejecutar y verifique queconnections.currenthaya vuelto a los niveles esperados en relaciónconnections.availablecon.Confirma que tus
mongodregistros o ya no muestran errores relacionados con la conexión.mongosEn las implementaciones de Atlas, confirme que el gráfico de recuento de conexiones en la vista Atlas Metrics haya vuelto a la línea base.
Diagnósticos para recopilar para obtener más apoyo
Si el problema persiste, póngase en contacto con el soporte técnico. Antes de contactar con el soporte, reúna la siguiente información:
Salida de
db.serverStatus()Fragmentos de registro de
mongodo que muestran errores o advertencias relacionados con lamongosconexión.Su cadena de conexión del controlador, específicamente con los valores
maxPoolSize,minPoolSizeywaitQueueTimeoutMS.Para implementaciones de Atlas, incluya:
El número de instancias de la aplicación y su topología de despliegue.
Una captura de pantalla del gráfico Atlas Connections durante el período en que ocurrió el problema.