MongoDB production environment performance and reliability considerations

This article is the MongoDB Production notes section of the translation http://www.aliyun.com/zixun/aggregation/13461.html ">mongodb Manuel. This section focuses on the various considerations that affect performance and reliability in the production environment, and is worth the attention of workers who are deploying MongoDB. This article describes in detail the key system configurations that affect MongoDB, especially the production environment. The following is the text.

installation package

Make sure you have the latest stable version installed. This is the best place to learn about the latest version, even if you later choose to install from the Package Manager.

The production environment always uses a 64-bit version. The 32-bit version is intended for testing and deployment environments and is not suitable for deployment in a production environment because it can only store data within 2GB. For more information, see the 32-bit limit.

The 32-bit version exists to meet the usage scenarios of the informal environment.

Operating

The MongoDB distribution is currently available for the Max OS x,linux,windows Server 2008 R2 64-Bit Edition, Windows 7 (32-bit and 64-bit Edition), Windows Vista, and the Solaris platform.

Note: When possible, MongoDB uses the GNU C Library (GLIBC). MongoDB requires that the version be at least glibc-2.12-1.2.el6 to avoid a known bug in the previous version. For best results, use at least 2.13 versions.

Concurrent

All write operations in earlier versions of MongoDB use only one read-write lock in the instance. Starting with 2.2, each database starts with a separate read-write lock, which allows a database to be read concurrently, with separate write controls for each database. View concurrent pages for more information.

Log

MongoDB uses the pre-write log to disk log to ensure that MongoDB can quickly recover from crashes or other serious errors.

To ensure that Mongod can recover from a crash and continue to be available, you should enable logging. View the log page for more information.

Internet

Using a trusted network environment

Always run MongoDB in a trusted environment and enable network policy to prohibit unknown machines, systems, and network access. Like any sensitive system that relies on network access, your MONGODB environment should only be developed for the specified, accessible system, such as application servers, monitoring services, and other MongoDB components.

Note: The authentication feature is not enabled by default, and Mongod infers that it is in a trusted environment. You can enable the Security authentication mode if necessary.

View the contents of the Security section for more information. Especially：

Configuration options

Firewall

Configuring the Linux iptables Firewall for MongoDB

Configuring Windows netsh firewall for MongoDB

For Windows users, consider the contents of the Windows Server TCP technology article when deploying MongoDB on Windows.

Connection pool

To prevent a single mongod or MONGOs instance from connecting the resource load, ensure that the client maintains a reasonable number of connection pool configurations.

The Connpoolstats Database command can return information about the current database open connection in the MONGOs and Mongod instances in a fragmented cluster.

Hardware Considerations

The MongoDB design is based on the compatibility of most hardware considerations with little specific requirements or limitations. MongoDB's core components are capable of running on small-byte-priority hardware, mainly on x86/x86_64 processors. A client class library, such as a driver, can be run on a big-endian or small-end priority system.

Hardware Requirements and limitations

The hardware that enables MongoDB to run most efficiently should include the following features:

Enough memory and CPU allocated

As with all software, more memory and faster CPU clock frequencies are important for performance.

Basically, the database is not restricted to CPU. As a result, increasing the core number, while helpful, will not provide significant returns.

Using solid-state drives (SSD)

MongoDB use SATA SSD for good results and good price/performance.

Use SSD if you have enough economy. Traditional hard disks can also be efficient, but SSD's good support for random IO access is more consistent with the Mongod data update model.

Traditional hard disks are usually a good choice, because using more expensive hard drives to improve random IO performance is not as effective (only twice times per time). Using SSD or increasing the capacity of RAM may be more efficient for improving IO.

Avoid using remote file systems

Remote file storage systems may cause performance problems for MongoDB. View the remote file system for more information about MongoDB and storage.

MongoDB and NUMA Hardware

Important: The NUMA discussed here is limited to Linux systems, so it does not affect running on other Unix-like systems or Windows systems.

Running MongoDB in systems running NUMA can cause a range of problems, including inefficiencies over time and high system usage.

When running MongoDB on NUMA hardware, you should disable NUMA for MongoDB and use the Interleave memory policy.

Note: If the MongoDB 2.0 version is deployed on a Linux system, the system configuration will be checked at startup and a warning will be given if the system is based on NUMA.

To disable NUMA and enable the Interleave memory policy, use NUMACTL and start the Mongod using the following methods

Numactl--interleave=all/usr/bin/local/mongod

Then, to disable zone reclaim in the proc configuration, use the following command:

echo 0 >/proc/sys/vm/zone_reclaim_mode

To completely disable NUMA, you must take two steps. For more information, check out the/proc/sys/vm/* documentation.

View the MySQL "Crazy swap" issue and the Numa effect, which describes the impact of NUMA on the database. This blog identifies the impact of Numa on MySQL, but the impact on MongoDB is similar. This article describes NUMA and its objectives, and points out why these goals are incompatible with the requirements of the production environment database.