Parameters to be aware of in the deployment of MongoDB

Deploy MongoDB's production server and give the following recommendations:

• Use of virtualized environments;
• System Configuration
  
  

1) Recommended RAID configuration

RAID (Redundant array of independent disk, redundant array of independent disks) is a technique that allows us to use multiple disks as a single piece of disk. It can be used to improve the reliability or performance of the disk, or both. A set of disks that use RAID technology is called a RAID disk array.

RAID depending on performance, there are a variety of configuration methods, often taking into account the speed and fault tolerance. The following are some of the most common configuration methods:

• RAID0
  Use disk striping to tie multiple disks together to improve performance. Each disk holds part of the data, similar to the shards in MongoDB. Because there are multiple underlying disks, large amounts of data can be written to disk at the same time. However, if one of the disks fails to cause data loss, there is no backup of the data, which can also slow down the read speed (especially on Amazon's elastic Block Store service).
  Because some data volumes may be slower than others.
• RAID1
  Use mirroring to improve reliability. The same copy of the data is written to each member of the array. This method has a lower performance than RAID0 because a slow member in the array slows down the entire array's write speed. However, if one of the disks fails, you can also find a copy of the data on the other members of the array.
• RAID5
  Based on the use of disk segmentation technology, additional data is stored in the verification information to prevent server failure resulting in data loss. In general, when a disk fails, the RAID5 can automatically process it, and the user does not feel a failure. However, this also makes RAID5 the slowest of these RAID configuration scenarios because it requires that the checksum be computed when the data is written. While MongoDB is just a typical number of times a small amount of data write work, so the cost of using RAID5 is particularly considerable.
• RAID10
  RAID10 is a combination of RAID0 and RAID1: Data is split to increase speed and mirrored to improve reliability.
  
  

It is recommended to use RAID10, which is more secure than RAID0 and can solve RAID1 performance problems. On the basis of the replica set, it is wasteful to use RAID1 to select RAID0.

Do not use RAID5, it will be very very slow.

2) Virtualization

A) Disable memory over-allocation

The setting value of memory overcommitting determines the policy to be taken when the process requests excessive memory to the operating system. Based on this setting, the kernel may allocate memory for the process, even if that memory is currently unavailable (the expected result is that it becomes available when the process uses the memory). This kernel-to-process promise of non-existent memory behavior is called memory over-allocation. This feature makes MongoDB not work well.

The value of Vm.overcomit_memory may be 0 (let the kernel guess the overallocated size), possibly 1 (satisfies all memory allocation requests), possibly 2 (the allocated virtual address space does not exceed the swap space and a small portion of the overallocated and). Setting this value to 2 represents the most complex and also the best choice. Run the following command to set this value to 2:

$ echo 2>/proc/sys/vm/overcommit_memory

After you change this setting, you do not have to restart MongoDB.

Under this directory,/proc/sys/vm/overcommit_memory

This file specifies the kernel's policy for memory allocation, which can be 0, 1, 2.

0, indicates that the kernel will check for sufficient available memory to be used by the process, and if sufficient memory is available, the memory request is allowed; otherwise, the memory request fails and the error is returned to the application process.

1, which means that the kernel allows all physical memory to be allocated regardless of the current memory state.

2, which indicates that the kernel allows allocating more memory than the sum of all physical memory and swap space (refer to Overcommit_ratio).

Default setting: 0

3) in the lookup document, the Linux proc on the disk performance parameters are involved, as follows:

MongoDB mmap do not call Fsync strong brush to disk, the operating system will also help us to automatically brush to disk, Linux has a dirty_writeback_centisecs parameter to define the amount of time the dirty data in memory (the default is 500, that is, 5 seconds), After this timeout time, the system will be brushed onto the disk. In the process of this auto-brush will block all IO operations, if you want to brush more data, easy to produce some long-time operations, such as some use Mmap program every time there will be a timeout operation, the general optimization method is to consider modifying the system parameters Dirty_writeback_ Centisecs, speed up the dirty page brush write frequency to reduce the long time. MongoDB is a timed strong brush and will not have this problem.

Under this directory,/proc/sys/vm/dirty_writeback_centisecs

This parameter controls the run interval of the kernel's dirty data refresh process Pdflush. The unit is 1/100 seconds. The default value is 500, which is 5 seconds. If your system is continuously writing to the action, then actually it is better to lower this value, so that the spike write operation can be flattened into multiple writes. The Setup method is as follows:

echo "/proc/sys/vm/dirty_writeback_centisecs" >

This value should be increased if your system is short-term, spike-type write operations, and the amount of data written is small (dozens of m/times) and the memory is more affluent:

echo "+" >/proc/sys/vm/dirty_writeback_centisecs

4) Log

Mongod By default sends logs to STDOUT (standard output, usually terminal). Most initialization scripts use the –logpath option to send logs to a file. If you have multiple MongoDB instances on the same machine (such as a mongod and a mongos), be sure to keep the logs of each instance in a separate file. Make sure you know where the log is stored and have read access to the file.

MongoDB will output a large number of log messages, but do not use the--quiet option (this option hides some of the log information). It is usually good to keep the log level as the default, when there is enough information in the Log for basic debugging (such as the reason for the time-consuming or startup exception), but the log takes up little space. When debugging a specific problem, you can use some options to get more information from the log.

First, when you restart MongoDB, you can complete the log level (Setparameter) changes by attaching more "V" (that is,-V,-VV,-VVV,-VVVV, or-VVVVV) to the parameters, or by running the following LogLevel command.

>db.admincommand ({"Setparameter": 1, "LogLevel": 3});

Remember to reset the log level to 0, otherwise there will be too much unnecessary content in the log. The log level can be increased to 5, when Mongod records almost all operations in the log, including what is processed by each request. Because Mongod writes everything to a log file, it can generate a lot of disk read and write operations (IO), slowing down a busy system. If you want to see all of the operations in progress immediately, it's a better idea to open the parser:

MongoDB default records take more than 100 milliseconds of query information. If 100 milliseconds is not available for an app, you can change this threshold by using the Setprofilinglevel command:

>//Record only query operations that take more than 500 milliseconds

> Db.setprofilinglevel (1,500)

{"was": 0, "slowms": +, "OK": 1}

>db.setprofilinglevel (0)

{"was": 1, "SLOWMS": $, "OK": 1}

The second instruction above closes the parser, but the value in milliseconds in the first instruction will continue to take effect as a threshold for logging in all databases. You can also change this threshold by restarting MongoDB with the-SLOWMS option.

Finally, set up a scheduled task to split (rotate) log files daily or weekly. If you use the –logpath option to start MongoDB, send a SIGUSR1 signal to the process even if it splits the log. You can also use the logrotate command to achieve the same purpose:

>db.admincommand ({"LogRotate": 1})

If MongoDB is not started with the--logpath option, the log cannot be split.

5) Close the atime of the database file

Preventing system-to-file access time updates can effectively improve the performance of file reads. This can be achieved by adding the noatime parameter to the /etc/fstab file. For example:

/dev/xvdb/data ext4 noatime 0 0

After you have modified the file, Mount it again:

# Mount-o Remount/data

6) Prohibit NUMA

On a multiprocessor Linux system that uses NUMA technology, you should prohibit the use of NUMA. MongoDB's performance in a NUMA environment can sometimes become slower, especially if the process is under high load.

Parameters to note in the deployment of MongoDB