Troubleshooting High Connection Utilization

Download

Focus Mode

Font Size

Last updated: 2026-10-23 20:44:38

AI-Translated

Problem description
The MongoDB service is provided in a mode where each network connection is processed by a single thread (one-thread-per-connection). Too many network connections generate too many threads, which will increase context switch and memory overheads. Establishing connections and performing authentication for each request greatly affect performance. Therefore, limiting the number of connections to an instance and releasing connections promptly after use is a prerequisite for ensuring the database stability.
Log in to the MongoDB console and view the trend chart of the Connection Percentage instance monitoring metric on the System Monitoring page. The connection percentage is the ratio of the current number of connections in the cluster to the maximum number of connections. If the maximum number of connections is reached, connection responses will slow down or even fail. Therefore, promptly troubleshoot the issue when the connection utilization exceeds 85%.
Troubleshooting
No.
Possible Cause
Troubleshooting Method
Solution
1
If a connection pool is used, improper connection parameter settings may occupy a large number of connection resources. For the meaning of connection pool parameters, see Connection Pool Usage Suggestions.
Check whether the configuration parameters of the client connection pool are suitable for the business scenario.
See Connection Pool Usage Suggestions to configure connection pool parameter settings.
2
There are many connections without actual service requests on the business side.
Use DBbrain's performance optimization feature to check whether the connections from clients to the business are actually needed by the business on the Real-Time Session page.
Use
DBbrain's
performance optimization feature to directly kill unnecessary clients on the Real-time Session page. For detailed directions, see Performance Optimization.
3
There are a high number of slow queries that occupy connections.
1. Use DBbrain's
performance optimization feature to query the records, execution statistics, and views of all current slow logs in the database on the Slow SQL Analysis page. For more information, see Performance Optimization.
2. Log in to the MongoDB console and click an instance ID to go to the Instance Details page. Select the Log Management tab and click Slow Log Query to identify specific slow queries through abstract analysis. For detailed query methods, see Slow Log Query.
For slow queries, perform index optimization.
Use DBbrain's index recommendation feature to select the optimal index.
Improve the database performance as instructed in Optimizing Indexes to Break Through Read/Write Performance Bottlenecks.
4
Connections are leaked, and unreleased connections exist.
Restart the instance. All instance connections will be interrupted at the moment of restarting mongos, but the business can be directly reconnected. Therefore, restarting mongos will not continuously affect the business. If the number of business connections increases rapidly and the connection utilization reaches 100% again after the restart, it indicates that the business does have a large number of valid connections and there are no connection leaks. For detailed directions, see Restarting Instance
Directly increase the number of connections in the console to temporarily sustain business surges. For detailed directions, see Connection Management.
Adjust the instance configuration. For replica set instances, upgrading the CPU and memory specifications of mongod can increase the maximum number of connections of the instance. For more information, see Adjusting Mongod Node Specification. For sharded clusters, upgrade the mongos node specification or add more shards as instructed in Adjusting Mongos Node Specification or Adjusting Shard Quantity respectively.
5
The current instance quota becomes insufficient as the business surges.
Refer to item 2.
﻿
Suggestions on connection pool usage
The following takes the Go language as an example to describe the parameters that need to be configured when the client connects to the database through a connection pool. For other programming languages, find the corresponding connection pool parameters for configuration. For more information, see Start Developing with MongoDB.
Parameter
Unit
Parameter Description
Configuration Suggestion
maxPoolSize
-
Configure the maximum number of connections that each client can apply for in the connection pool.
The product of this parameter and the number of clients must be less than the maximum number of connections of the instance; otherwise, if there are excessive connections, new connections cannot be established.
minPoolSize
-
Configure the minimum number of connections that each client can apply for in the connection pool.
The product of this parameter and the number of clients must be less than the maximum number of connections of the instance; otherwise, if many new connections need to be established during business surges, backend instance resources will become insufficient.
socketTimeoutMS
ms
Configure the wait timeout period for sending and receiving sockets. The default value is 
Set this parameter according to your actual business scenario so as to avoid that when a MongoDB server failure causes a primary/secondary switch, the client will not be able to receive the packet of the server response, resulting in prolonged use of resources by this invalid connection.
maxIdleTimeMS
ms
Configure the maximum time an idle connection exists before it is deleted or closed.
Set this parameter to be within 1 hour to avoid idle connections occupying connection resources all the time.
heartbeatFrequencyMS
ms
Configure the frequency at which the client sends heartbeats to the server. This parameter is used by the client to periodically check the status of the connection to the backend database.
Set this parameter to be within 10s, so that the status of the server can be checked as soon as possible to avoid generating invalid connections.
FAQs
If the number of connections exceeds the limit, increase the number of connections or restart the instance to resolve the issue. For more information, see Solutions to Connection Limit Exceeded.

Help and Support

Was this page helpful?

You can also Contact sales or Submit a Ticket for help.

Help us improve! Rate your documentation experience in 5 mins.

Feedback

tencent cloud

TencentDB for MongoDB

Troubleshooting High Connection Utilization

Problem description

Troubleshooting

Suggestions on connection pool usage

FAQs

Help and Support

No.	Possible Cause	Troubleshooting Method	Solution
1	If a connection pool is used, improper connection parameter settings may occupy a large number of connection resources. For the meaning of connection pool parameters, see Connection Pool Usage Suggestions.	Check whether the configuration parameters of the client connection pool are suitable for the business scenario.	See Connection Pool Usage Suggestions to configure connection pool parameter settings.
2	There are many connections without actual service requests on the business side.	Use DBbrain's performance optimization feature to check whether the connections from clients to the business are actually needed by the business on the Real-Time Session page.	Use DBbrain's performance optimization feature to directly kill unnecessary clients on the Real-time Session page. For detailed directions, see Performance Optimization.
3	There are a high number of slow queries that occupy connections.	1. Use DBbrain's performance optimization feature to query the records, execution statistics, and views of all current slow logs in the database on the Slow SQL Analysis page. For more information, see Performance Optimization. 2. Log in to the MongoDB console and click an instance ID to go to the Instance Details page. Select the Log Management tab and click Slow Log Query to identify specific slow queries through abstract analysis. For detailed query methods, see Slow Log Query.	For slow queries, perform index optimization. Use DBbrain's index recommendation feature to select the optimal index. Improve the database performance as instructed in Optimizing Indexes to Break Through Read/Write Performance Bottlenecks.
4	Connections are leaked, and unreleased connections exist.	Restart the instance. All instance connections will be interrupted at the moment of restarting mongos, but the business can be directly reconnected. Therefore, restarting mongos will not continuously affect the business. If the number of business connections increases rapidly and the connection utilization reaches 100% again after the restart, it indicates that the business does have a large number of valid connections and there are no connection leaks. For detailed directions, see Restarting Instance	Directly increase the number of connections in the console to temporarily sustain business surges. For detailed directions, see Connection Management. Adjust the instance configuration. For replica set instances, upgrading the CPU and memory specifications of mongod can increase the maximum number of connections of the instance. For more information, see Adjusting Mongod Node Specification. For sharded clusters, upgrade the mongos node specification or add more shards as instructed in Adjusting Mongos Node Specification or Adjusting Shard Quantity respectively.
5	The current instance quota becomes insufficient as the business surges.	Refer to item 2.

Parameter	Unit	Parameter Description	Configuration Suggestion
maxPoolSize	-	Configure the maximum number of connections that each client can apply for in the connection pool.	The product of this parameter and the number of clients must be less than the maximum number of connections of the instance; otherwise, if there are excessive connections, new connections cannot be established.
minPoolSize	-	Configure the minimum number of connections that each client can apply for in the connection pool.	The product of this parameter and the number of clients must be less than the maximum number of connections of the instance; otherwise, if many new connections need to be established during business surges, backend instance resources will become insufficient.
socketTimeoutMS	ms	Configure the wait timeout period for sending and receiving sockets. The default value is	Set this parameter according to your actual business scenario so as to avoid that when a MongoDB server failure causes a primary/secondary switch, the client will not be able to receive the packet of the server response, resulting in prolonged use of resources by this invalid connection.
maxIdleTimeMS	ms	Configure the maximum time an idle connection exists before it is deleted or closed.	Set this parameter to be within 1 hour to avoid idle connections occupying connection resources all the time.
heartbeatFrequencyMS	ms	Configure the frequency at which the client sends heartbeats to the server. This parameter is used by the client to periodically check the status of the connection to the backend database.	Set this parameter to be within 10s, so that the status of the server can be checked as soon as possible to avoid generating invalid connections.