The error analysis of setting failure of MongoDB maximum connection number

Background Introduction:

Querying MongoDB configuration parameters, you can know that the parameter about the maximum number of connections is Maxconns. However, after you connect the instance, look for the maximum number of connections that are supported, or the default of 819.

Description: The maximum number of connections is determined by the total number of maximum file descriptors that can be opened by Maxconn (Maxincomingconnections) and the operating system single process, taking the minimum value between two. The default number of maximum file descriptors that a single process can open is 1024,1024*80% = 819.2 takes an integer of 819. So the maximum number of concurrent connections that can be supported is 819.

Case Replay

The following parameters are configured for this test MongoDB case.

View the maximum number of connections after startup.

Run command: Db.serverstatus (). connections

Current indicates the number of connections that are currently running on the instance.

Available indicates the number of concurrent connections that the current instance can also support.

This means that the maximum number of concurrent connections that this instance can support is: current+available=3+816=819.

So the set Maxconns parameter is not valid. So the set Maxconns parameter is invalid! So the set Maxconns parameter is invalid! So the set Maxconns parameter is invalid!

Quest for answers

At this time to view the relevant information on the Internet, most of the Linux system to focus on the maximum number of file descriptors. Check out our system configuration, which is now 65535. is not limited by the maximum number of system file descriptors.

Turn around because we are CentOS 7 for the operating system, so our MongoDB service is managed through SYSTEMCTL. What if this service is managed through a services command?

Test 1 Test Service to manage the impact of MONGODB services on the maximum number of connections

(1) Create a service named mongodbtest0903 under the/ETC/INIT.D directory;

(2) The service is configured as follows:

(3) Give execution permission and then turn on the service

(4) View the number of connections at this time is 2500 (Maxconns parameter value)

(5) Close MongoDB Service

The above instructions use service to manage services, the maximum number of connections parameter is working.

Test 2 If you open it directly with MongoDB command?

(1) Open directly

(2) View the number of connections at this time is 2500 (Maxconns parameter value)

(3) Close this service

The above instructions directly open the MongoDB service, the maximum number of connections parameters have worked.

through the service and MongoDB command to start the service, the maximum number of connections is the set parameter, and the Systemctl to turn on this service becomes the default 819.

Explore

Let us specifically analyze the MongoDB service (this service is defined as mongodbtest0903) that is systemctl open.

(1) command to view all configuration details for this service

Systemctl Show Mongodbtest0903.service

Some details are as follows

At this time limitnofile=4096

(2) The process of viewing this service, and the resource limits under this process

Resource limits for processes

Finally see the resource limit is 1024.

Question 1: Why the SYSTEMCTL-initiated MongoDB service becomes the default 819.

Answer: Because the SYSTEMCTL started the service process, its maximum number of file descriptors becomes 1024. 1024*80% = 819.2 takes an integer of 819.

Question 2: Why the system is set to a maximum of 65525 and Systemctl becomes 1024.

In the CENTOS7 system, the previous sysv was replaced with SYSTEMD. The configuration scope of the/etc/security/limits.conf file is reduced. /etc/security/limits.conf configuration, only applies to the user's resource limit through Pam authentication, it does not take effect on the resource limit of SYSTEMD service.

In fact, carefully review the comments of the/etc/security/limits.conf file, stating that the system service does not take effect.

Solution Solutions

Solution, knowing where the problem is, finding a solution to the problem is relatively easy.

Solution 1: Services managed for a single systemctl.

Find specific services in/lib/systemd/system to increase

# (open files)

limitnofile=64000

Command. Modified to:

Restart the service, at which point the connection views the maximum number of connections to 2500, which reaches the set parameters.

Solution 2 There is a solution to the SYSTEMD global modification. This scenario is not verified by the author, as follows, meaning to modify the/etc/systemd/system.conf:

Global configuration, placed in Files/etc/systemd/system.conf and/etc/systemd/user.conf. At the same time, all the. conf files in the two corresponding directories are loaded/etc/systemd/system.conf.d/*.conf and/etc/systemd/user.conf.d/*.conf
Where system.conf is used by the system instance, user.conf the user instance. General Sevice, use the configuration in the system.conf. Configuration in systemd.conf.d/*.conf overrides System.conf.

Defaultlimitcore=infinity

defaultlimitnofile=100000

defaultlimitnproc=100000

Note: After you modify the system.conf, you need to restart the system before it takes effect.

Because Systemctl on the server manages a variety of services, it is recommended that the first scenario be modified on a single service to reduce the impact on other services.

Other related knowledge

(1) MySQL service will also encounter similar problems;

(2) * Nofiles-soft limit on the number of file descriptors a process may has;

(3) The difference between *soft limit and hard limit: soft limit is a really effective limiting value, and hard limit is only an upper limit of the soft limit adjustment range.