- Release Notes and Announcements
- User Guide
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Access Management
- Instance Management
- Node Management
- Version Upgrade
- Monitoring
- Backup and Rollback
- Data Security
- SSL Authentication
- Database Management
- Multi-AZ Deployment
- Public Network Access
- Disaster Recovery/Read-Only Instances
- Parameter Configuration
- Recycle Bin
- Task Management
- Performance Optimization
- Data Migration Guide
- Best Practice
- Optimizing Indexes to Break Through Read/Write Performance Bottlenecks
- Troubleshooting Mongos Load Imbalance in Sharded Cluster
- Troubleshooting Excessive Slow Queries
- Fixing High CPU Utilization in MongoDB Instance Based on DBbrain
- Troubleshooting Excessive Connections
- Troubleshooting High Request Latency Based on Slow Log
- Troubleshooting High CPU Utilization
- Considerations for Using Shard Clusters
- Sample of Reading and Writing Data in MongoDB Instance
- Export and Import
- Troubleshooting MongoDB Connection Failures
- Performance Fine-Tuning
- Ops and Development Guide
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- RenameInstance
- OfflineIsolatedDBInstance
- ModifyDBInstanceSpec
- IsolateDBInstance
- DescribeSpecInfo
- DescribeDBInstances
- DescribeClientConnections
- CreateDBInstanceHour
- AssignProject
- RenewDBInstances
- DescribeSlowLogs
- DescribeSlowLogPatterns
- InquirePriceRenewDBInstances
- InquirePriceModifyDBInstanceSpec
- InquirePriceCreateDBInstances
- DescribeDBInstanceDeal
- DescribeSecurityGroup
- DescribeInstanceParams
- ModifyDBInstanceSecurityGroup
- ModifyDBInstanceNetworkAddress
- Backup APIs
- Account APIs
- Task APIs
- Other APIs
- Data Types
- Error Codes
- Instance Connection
- FAQs
- Service Agreement
- Glossary
- Contact Us
- Release Notes and Announcements
- User Guide
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Access Management
- Instance Management
- Node Management
- Version Upgrade
- Monitoring
- Backup and Rollback
- Data Security
- SSL Authentication
- Database Management
- Multi-AZ Deployment
- Public Network Access
- Disaster Recovery/Read-Only Instances
- Parameter Configuration
- Recycle Bin
- Task Management
- Performance Optimization
- Data Migration Guide
- Best Practice
- Optimizing Indexes to Break Through Read/Write Performance Bottlenecks
- Troubleshooting Mongos Load Imbalance in Sharded Cluster
- Troubleshooting Excessive Slow Queries
- Fixing High CPU Utilization in MongoDB Instance Based on DBbrain
- Troubleshooting Excessive Connections
- Troubleshooting High Request Latency Based on Slow Log
- Troubleshooting High CPU Utilization
- Considerations for Using Shard Clusters
- Sample of Reading and Writing Data in MongoDB Instance
- Export and Import
- Troubleshooting MongoDB Connection Failures
- Performance Fine-Tuning
- Ops and Development Guide
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- RenameInstance
- OfflineIsolatedDBInstance
- ModifyDBInstanceSpec
- IsolateDBInstance
- DescribeSpecInfo
- DescribeDBInstances
- DescribeClientConnections
- CreateDBInstanceHour
- AssignProject
- RenewDBInstances
- DescribeSlowLogs
- DescribeSlowLogPatterns
- InquirePriceRenewDBInstances
- InquirePriceModifyDBInstanceSpec
- InquirePriceCreateDBInstances
- DescribeDBInstanceDeal
- DescribeSecurityGroup
- DescribeInstanceParams
- ModifyDBInstanceSecurityGroup
- ModifyDBInstanceNetworkAddress
- Backup APIs
- Account APIs
- Task APIs
- Other APIs
- Data Types
- Error Codes
- Instance Connection
- FAQs
- Service Agreement
- Glossary
- Contact Us
Troubleshooting High Connection Utilization
Last updated: 2024-01-15 14:49:55
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 TencentDB for MongoDB console, select the System Monitoring page, and view the trend chart of the instance monitoring metric Connection Percentage. This metric refers to the ratio of the number of connections in the current cluster to the maximum number of connections. If the maximum number of connections is reached, the connection response will slow down, and even connections will fail. Therefore, when the connection utilization exceeds 85%, check and handle it in time.
Troubleshooting
No. | Possible Cause | Troubleshooting Method | Solution |
1 | If a connection pool is used, a lot of connection resources may be used due to the unreasonable configuration of connection parameters. | Check whether the configuration parameters of the client connection pool are suitable for the business scenario. | Configure connection pool parameters as detailed below. |
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 TencentDB for MongoDB console, click the instance ID to enter the Instance Details page, select the Database Management tab, click Slow Log Query, and select Query statistics to query slow queries. For detailed directions, see Slow Log Management. | 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 | There are unreleased connections due to connection leaks. | 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 | 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 0, indicating not to time out. | 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. |
Yes
No
Was this page helpful?