The main content of this article comes from MongoDB Official document Http://docs.mongodb.org/manual/administration/production-notes/. and combined with the actual work of the situation to share.
1) Selection of packages
Be sure to use the latest stable version. The current version we use online is 2.4.6. MongoDB package download page http://www.mongodb.org/downloads.
Ensure that the online environment always uses the 64-bit version. The 32-bit version can only be used for testing and development, since the 32-bit version can store only 2GB of data. When you start MongoDB, MongoDB automatically detects whether it is a 32-bit version, and if it is a 32-bit version, a message will appear.
MongoDB Shell version:2.4.6
Connecting To:127.0.0.1:28018/test
Server has startup warnings:
Mon Jan 6 17:04:47.040 [Initandlisten]
Mon Jan 6 17:04:47.040 [Initandlisten] * * Note:this is a A-bit MongoDB binary.
Mon Jan 6 17:04:47.040 [Initandlisten] * * + builds is limited to less than 2GB of data (or less with--journa L).
Mon Jan 6 17:04:47.040 [Initandlisten] * * Note that journaling defaults to off for the + and is currently off.
Mon Jan 6 17:04:47.040 [Initandlisten] * * See Http://dochub.mongodb.org/core/32bit
Mon Jan 6 17:04:47.040 [Initandlisten]
>
MongoDB does not support 32-bit storage for more than 2GB of data, the official explanation is that MongoDB's storage engine uses memory-mapped files, a memory-mapped file, to improve performance. And let the 32-bit version do not store more than 2GB of data, MongoDB team can reduce the number of code, reduce the number of bugs, and from the hardware, more and more people use 64-bit hardware to deploy online services. So, make sure that the packages deployed to the line are 64-bit, not 32-bit, otherwise it's tragic.
2) Choice of operating system
MongoDB supports Windows,linux,macos and Solaris. Download the appropriate version from the download page http://www.mongodb.org/downloads, and remember to use the stable version. At the moment, we are using CentOS6.4 x86_64 on line. MongoDB needs to use GLIBC-2.12-1.2.EL6 or more versions of GLIBC.
3) concurrency
In earlier versions, all writes in one MongoDB instance competed with one Readers-write lock. After the 2.2 release, the libraries in each instance have a Readers-write lock that allows concurrent reads of the library, but only a single write operation. Detailed operation can refer to http://docs.mongodb.org/manual/faq/concurrency/.
4) Log function
MongoDB uses advance write logging to log on to disk to ensure that MongoDB can quickly resume write operations from system crashes or other serious accidents. The 64-bit version turns on logging by default, and 32-bit is not turned on. Detailed operation can refer to http://docs.mongodb.org/manual/core/journaling/.
5) Network aspects
Always run MongoDB in a trusted environment, set network access rules, do not allow ambiguous hosts, system or network access to MongoDB server. As with other sensitive systems that rely on network access, when you deploy MongoDB, you also need to set which specific systems allow access. If the Web server can access the MongoDB server, the monitoring server can access the MongoDB server. The Auth feature is not turned on by default, and MongoDB assumes that the currently running environment is a secure environment. The AUTH function can be turned on as needed.
http://docs.mongodb.org/manual/tutorial/configure-linux-iptables-firewall/configuration iptables.
6) Connection Pool
To avoid excessive connection resource load on a single MongoDB instance or MONGOs instance payload, ensure that all clients need to maintain a reasonable connection pool size.
7) Hardware-related considerations
1. Allocate enough CPU and memory to the MONGODB server
MongoDB, like other software, allocates more memory and faster CPUs to improve performance. In the case of online operation, MongoDB really eats memory, and it tries to eat up the memory first.
2. Assigning swap
You need to allocate a swap partition to the system that is running MongoDB, and to avoid an OOM killer kill the MongoDB process in the event of intense memory contention.
MongoDB ensures that the operating system does not store mongodb data into the swap partition by mapping memory files to memory.
3.RAID related
In most cases, the deployment of MongoDB should consider using RAID10.
4. Use SSD solid state Disks as much as possible
Use SSDs whenever possible, as SSDs have high performance for a large number of random reads and writes. In the case of online use, MongoDB gets better performance by using disks with higher IOPS values.
5. Do not use remote file system (NFS)
Network File system NFS is not recommended for MONGODB deployments, which is prone to performance issues. MongoDB generates many performance problems when both data and log files are stored on NFS, and the log files are stored on local or iSCSI volume groups for better performance. If you do not want to use NFS, you need to add Bg,noclock,noatime in the/etc/fstab.
6. Store the data separately
For greater performance, you can store data files, system log files, and access log files on separate storage devices. However, this affects how the snapshot backs up data.
8) MongoDB and NUMA hardware
Running MongoDB on a NUMA (Non-uniform Access Memory) system can produce many operations-related issues, including
Intermittent slow queries and system processes for high-load use.
When using MongoDB on a NUMA hardware, you need to turn off NUMA and then set the Interleave memory policy. When you deploy MongoDB on Linux, MongoDB 2.0 or later detects NUMA settings at startup and prompts for warning messages.
can use
Numactl--interleave=all/usr/bin/local/mongod
Turn off Numa.
RPM Package installation of MongoDB after the startup script/etc/init.d/mongod has already handled the NUMA accordingly
# Handle NUMA access to CPUs (SERVER-3574)
# This verifies the existence of NUMACTL as well as testing that the command works
Numactl_args= "--interleave=all"
If which numactl >/dev/null 2>/dev/null && numactl $NUMACTL _args ls/>/dev/null 2>/dev/null
Then
Numactl= "NUMACTL $NUMACTL _args"
Else
Numactl= ""
Fi
Use echo 0 >/proc/sys/vm/zone_reclaim_mode to turn off Numa in Proc. For more information, refer to
Https://www.kernel.org/doc/Documentation/sysctl/vm.txt
9) Deploying MongoDB on Linux
1. Selection of kernel and file system
The official recommendation is to use the Linux kernel version 2.6.36 future versions. CentOS 6 The default kernel is 2.6.32. Currently there is no special adjustment on the line, there is strength to compile the kernel on its own.
MongoDB allocates database files prior to using the database files, often generating many large files. So you should use the EXT4 or XFS file system.
Typically, if you want to use the EXT4 file system, you need to use kernel 2.6.23 or more kernel versions.
If you use the XFS file system, you need to use kernel 2.6.25 or more of the kernel version.
Some Linux distributions require different kernel versions to support the EXT4 or XFS file system
Linux Distribution Filesystem Kernel Version
CentOS 5.5 ext4, XFS 2.6.18-194.el5
CentOS 5.6 Ext4, XFS 2.6.18-238.el5
CentOS 5.8 ext4, XFS 2.6.18-308.8.2.el5
CentOS 6.1 Ext4, XFS 2.6.32-131.0.15.el6.x86_64
RHEL 5.6 EXT4 2.6.18-238
RHEL 6.0 XFS 2.6.32-71
Ubuntu 10.04.4 LTS ext4, XFS 2.6.32-38-server
Amazon Linux AMI release 2012.03 Ext4 3.2.12-3.2.4.amzn1.x86_64
2. Recommended configuration
Close the atime of the disk that stores the database files. As set
/dev/vdb/data ext4 defaults,noatime 0 0
Sets the value of Ulimit-n and ulimit-u greater than 20000. If the value of Ulimit is set too low, when MongoDB is in a state of frequent access, an error will result, resulting in the inability to connect to the MongoDB instance.
Close transparent huge pages. MongoDB has better performance with normal virtual memory pages (4096bytes).
Turn off NUMA in the BIOS.
Synchronize host time with NTP.
Make sure that the read-ahead setting (Readahaed settings) of the block device that stores the database file is reasonable. corresponding to random access, set a lower read-ahead setting value.
10) Performance Monitoring
Use of Iostat and bwm-ng to monitor disk and network usage
$ IOSTAT-XMT 1
Linux 2.6.32-358.14.1.el6.x86_64 (ZG-JIDONG-MONGODB) 04/09/2014 _x86_64_ (CPU)
04/09/2014 06:00:34 PM
AVG-CPU:%user%nice%system%iowait%steal%idle
1.77 0.00 0.50 0.74 0.09 96.90
device:rrqm/s wrqm/s r/s w/s rmb/s wmb/s avgrq-sz avgqu-sz await SVCTM%util
VDA 0.00 0.83 0.00 0.03 0.00 0.00 214.45 0.00 92.90 6.03 0.02
VDB 0.00 68.53 0.27 71.77 0.01 0.61 17.80 0.00 0.01 1.94 13.99
Avgrq-sz the average size (in sectors) of the requests, were issued to the device. The average size of requests related to the current device (in number of sectors), the smaller the number represents the more random requests
%util Percentage of CPU time during which I/O requests were issued to the device (bandwidth Utilization for the device). Device saturation occurs when the this value was close to
100%. The value of this parameter is very useful, indicating that the current device (disk) has a related request CPU utilization, if the value is close to 100% indicates that the disk has reached saturation
(GO) Online environment Deployment MongoDB's official recommendation