Description of production environment for "five" MongoDB management

The following is a detailed description of the system configuration that affects MongoDB, especially in the production environment.

1, the production environment recommended platform

• Amazon Linux
• Debian 7.1
• Red Hat/centos 6.2+
• SLES 11+
• Ubuntu LTS 12.04
• Ubuntu LTS 14.04
• Windows Server & R2

It is recommended to use the official latest 64-bit release.

2. Network configuration

1) Use a trusted network environment

MongoDB is always running in a trusted network environment, with network rule settings to avoid all unknown machine accesses. MongoDB should be deployed in a standalone environment that can only be accessed by the application server, monitoring services, MongoDB components, and so on.

2) Disable HTTP interface

3. Connection Pool Management

To avoid connection overloading, ensure that the client maintains a reasonable connection pool size, adjusts the connection pool size to suit the case, and generally, the start connection pool size is set to the 110-115% of the database request concurrency number.

4, hardware configuration instructions

MongoDB has certain requirements and limitations for the hardware of the server.

1) Allocate sufficient CPU and RAM

• For the MMAPV1 storage Engine: Because of its own concurrency model design, MMAPV1 does not require more CPU cores, so increasing the CPU core is somewhat helpful but performance gains are not significant. Increasing RAM can help reduce the frequency of paging errors.
• For the Wiredtiger storage engine: It is designed for multithreading and can take advantage of many CPU cores, so the total number of active threads corresponds to the number of CPUs that can improve performance. As the number of active concurrent operations increases to the number of system CPUs, the system throughput increases, and the system throughput decreases with the number of active concurrent operations exceeding the number threshold of the system CPU.

The number of system thresholds depends on your application, and you can experiment with measuring system throughput to determine the optimal number of active concurrency. The output of the Mongostat tool can provide active concurrent read and write data. In the v3.2 version, the Wiredtiger storage engine is used by default, and MongoDB can take advantage of the OS file system cache and the cache of the Wiredtiger engine. Wiredtiger v3.2 Cache is set to 1GB or 60% of the memory by default, whichever is larger. Of course, we can set ourselves: Generally, the server physical memory 10G or less, the more reasonable setting value is smaller than or equal to 3G, for physical memory greater than 10G, can be greater than 3G. In the v3.0 version, the cache defaults to 1G or half of the physical memory, whichever is larger.

Note:Storage.wiredTiger.engineConfig.cacheSizeGB only limits the Wiredtiger cache size, and does not limit the amount of memory that the MONGD service consumes. Wiredtiger cache is just one component of MongoDB using memory, and MongoDB can also take advantage of the file system cache in the operating system.

If there is only one MongoDB instance on a node, it is recommended to use the default Wiredtiger cache, and if there are multiple instances on one node, you need to consider reducing the size of the Wriedtiger cache to meet the needs of other instances.

2) using SSDs (Solid State Drive)

MongoDB has a very good price/performance ratio on SATA SSDs. If economic conditions permit, it is advisable to use SSDs. The performance of SSDs on the random IO operation is fully adapted to the update model of the MMAPV1 storage engine. Improves I/O throughput by using SSDs and increasing memory

3) NUMA settings

MongoDB runs on NUMA systems and can cause some operational problems, such as low intermittent performance, high system process occupancy, and so on. Therefore, the memory crossover policy needs to be configured so that the host is Non-numa state, and MongoDB checks the system's NUMA at startup, and warns if the NUMA configuration degrades performance.

• NUMA configuration on Windows systems

Memory policy through the BIOS configuration, please refer to the System Information

• NUMA configuration on Liunx systems

Numactl--interleave=all <path>   #path是mongod路径echo 0 >/proc/sys/vm/zone_reclaim_mode

4) disk Storage System

• Swap allocation: Allocate system swap space to avoid memory contention and prevent the system from having problems such as oom killing Mongod process. For the MMAPV1 storage engine, MongoDB does not store data in the swap space. (Windows environment is counted); for the Wiredtiger storage engine, MongoDB may store data in swap.
• RAID: Recommended to use RAID10, others are not recommended.
• File system type selection: for MMAPV1 storage engines, XFS or EXT4 are recommended, and if possible, XFS is preferred. For Wiredtiger storage engines, it is highly recommended to use the XFS file system because it avoids the performance issues that are generated by using EXT4. In general, if you use the XFS file system, the operating system kernel version should be 2.6.25 and later, if you use the Ext4 file system, the kernel version 2.6.23 and later is recommended.

5. Other recommended configurations (LIUNX)

• For disk volumes that store database files, it is recommended that you close Atime

vim/etc/fstab# on the disk volume device on which the database file is stored, add noatime,nodiratime after default Uuid=98a683e4-ab44-4fe4-85de-7808ee5f167d/data                   XFS     defaults,noatime,nodiratime        1 2

• Set Unlimit value greater than 20000
• Disable Transparent Huge Pages
• disabling NUMA
• Set SELinux on Red Hat
• If you are using a shard cluster, it is particularly important that you do not forget the time it takes to synchronize hosts with NTP.

Description of production environment for "five" MongoDB management