(转) 线上环境部署MongoDB的官方建议

本文主要内容来自MongoDB官方文档http://docs.mongodb.org/manual/administration/production-notes/。并结合了实际工作情况进行分享。

1)软件包的选择

确保使用最新的稳定版本。目前我们线上使用的版本是2.4.6。MongoDB软件包下载页面http://www.mongodb.org/downloads

确保线上环境总是使用64位版本。32位版本只能用于测试和开发使用,因为32位版本最大只能存储2GB的数据。启动MongoDB的时候,MongoDB会自动检测是否是32位版本,如果是32位版本,则会有提示信息显示。

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 32 bit MongoDB binary.

Mon Jan  6 17:04:47.040 [initandlisten] **       32 bit builds are limited to less than 2GB of data (or less with --journal).

Mon Jan  6 17:04:47.040 [initandlisten] **       Note that journaling defaults to off for 32 bit 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不支持32位存储2GB以上的数据,官方给出的解释是MongoDB的存储引擎使用memory-mapped files即内存映射型文件来提高性能。并且让32位版本不存储2GB以上的数据,MongoDB团队可以减少代码数量,减少bug数量,并且从硬件上来说,越来越多的人使用64位硬件来部署线上服务。所以,确保部署到线上的软件包是64位的,而不是32位的,要不然就悲剧了。

2)操作系统的选择

MongoDB支持Windows,Linux,MacOS和Solaris。从下载页面http://www.mongodb.org/downloads 下载相应的版本即可,记得使用稳定版本。目前,我们线上使用的是CentOS6.4 x86_64。MongoDB需要使用glibc-2.12-1.2.el6以上版本的glibc。

3)并发性

在早期的版本中,一个MongoDB实例中的所有写操作都共同竞争使用一个readers-write 锁。在2.2版本以后,每个实例中的库都有一个readers-write 锁,可以允许这个库的并发读取,但是只能进行单次写入操作。详细操作可以参考http://docs.mongodb.org/manual/faq/concurrency/

4)日志功能

MongoDB使用提前写日志记录到磁盘上的日志方式来确保MongoDB可以快速的从系统奔溃或其他严重事故中恢复写操作。64位版本默认开启日志功能,32位没有开启。详细操作可以参考http://docs.mongodb.org/manual/core/journaling/

5)网络方面

总是在一个可受信任的环境中运行MongoDB,设置网络访问规则,不允许不明确的主机,系统或网络访问MongoDB服务器。正如其他依赖于网络访问的敏感系统一样,部署MongoDB的时候,也需要设定有哪些特定系统允许访问。如设定WEB服务器可以访问MongoDB服务器,监控服务器可以访问MongoDB服务器。默认情况下auth功能没有开启,MongoDB假定当前运行的环境是一个安全的环境。根据需要可以开启auth功能。

http://docs.mongodb.org/manual/tutorial/configure-linux-iptables-firewall/ 配置iptables。

6)连接池

为了避免单个MongoDB实例或Mongos实例负载的连接资源负载过高,确保所有客户端需要维护一个合理的连接池大小。

7)硬件相关考虑

1.分配给MongoDB服务器足够的CPU和内存

MongoDB和其他软件一样,分配越多的内存和越快的CPU都可以提升性能。从线上运行情况来看,    MongoDB确实很吃内存,它会尽量先吃光内存。

2.分配swap

需要给运行MongoDB的系统分配swap分区,避免在内存竞争激烈的情况下,OOM Killer杀掉MongoDB进程。

MongoDB通过映射内存文件到内存的方式确保操作系统不会存储MongoDB数据到swap分区。

3.RAID相关

大多数情况下,部署MongoDB都应该考虑使用RAID10。

4.尽量使用固态硬盘Solid State Disks

在条件允许的情况下,尽量使用SSD,因为SSD对大量随机读写有很高的性能。从线上使用的情况    来看,使用IOPS值越高的磁盘,MongoDB获取的性能越好。

5.不要使用远程文件系统(NFS)

不建议网络文件系统NFS用于MongoDB部署,这样容易产生性能问题。当数据文件和日志文件都存    储在NFS上时,MongoDB就会产生很多性能问题,将日志文件存储在本地或iscsi卷组上,可以获    得好一点的性能。如果非要使用NFS,则在/etc/fstab中需要加上bg,noclock,noatime。

6.将数据分开存储

为了获得更大的性能,可以将数据文件,系统日志文件和访问日志文件分别存储到不同的存储设   备上。但是这样会影响快照方式备份数据。

8)MongoDB和NUMA硬件

在一个NUMA(Non-Uniform Access Memory)的系统上运行MongoDB会产生许多运维相关问题,包括

间断性的慢查询和系统进程高负载使用。

在一个NUMA硬件上使用MongoDB时,需要关闭NUMA,然后设置interleave内存策略。在Linux上部    署MongoDB时,MongoDB 2.0以上版本在启动时会检测NUMA设置,并提示警告信息。

可以使用

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

关闭NUMA。

RPM包安装MongoDB后的启动脚本/etc/init.d/mongod已经对NUMA作了相应的处理

# 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

使用echo 0 > /proc/sys/vm/zone_reclaim_mode 在proc中关闭NUMA。详细信息可以参考

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

9)在Linux上部署MongoDB

1.内核和文件系统的选择

官方建议使用Linux内核版本2.6.36以后的版本。CentOS 6以上默认的内核是2.6.32.目前线上      没有作特殊调整,有实力的话可以自行编译内核。

MongoDB在使用数据库文件之前会预先分配数据库文件,通常会生成许多大文件。所以应该使      用EXT4或XFS文件系统。

通常情况下,如果要使用EXT4文件系统的话,需要使用内核2.6.23以上的内核版本。

如果使用XFS文件系统的话,需要使用内核2.6.25以上的的内核版本。

一些Linux发行版需要不同的内核版本来支持EXT4或XFS文件系统

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.建议配置

关闭存储数据库文件的磁盘的atime。如设置

/dev/vdb /data ext4 defaults,noatime 0 0

设置ulimit -n和ulimit -u的值大于20000。如果ulimit的值设置过低的话,当MongoDB处于       频繁访问的状态下,将会产生错误,最终导致无法连接到MongoDB实例。

关闭transparent huge pages。MongoDB在使用正常虚拟内存页面(4096bytes)性能更好。

在BIOS中关闭NUMA.

使用NTP同步主机时间。

确保存储数据库文件的块设备的预读设置(readahaed settings)是否合理。对应随机访           问,设置一个较低的预读设置值。

10)性能监控

使用iostat和bwm-ng可以监控磁盘和网络使用情况

$ iostat -xmt 1

Linux 2.6.32-358.14.1.el6.x86_64 (zg-jidong-mongodb) 04/09/2014 _x86_64_(16 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 that were issued to the device.

当前设备相关的请求的平均大小(以扇区数量计算),数值越小代表随机请求越多

%util             Percentage of CPU time during which I/O requests were issued to the device (bandwidth

utilization for the device). Device saturation occurs when this  value  is  close  to
                    100%.

这个参数的值非常有用,表示当前设备(磁盘)有相关请求时的CPU占用率,这个值如果接近100%时表示磁盘已经到达饱和状态

时间: 2024-10-18 00:09:41

(转) 线上环境部署MongoDB的官方建议的相关文章

Docker + node(koa) + nginx + mysql 线上环境部署

在上一篇 Docker + node(koa) + nginx + mysql 开发环境搭建,我们进行了本地开发环境搭建 现在我们就来开始线上环境部署 如果本地环境搭建没有什么问题,那么线上部署的配置也就很简单了 我所使用的环境,Linux Mint,命令有不同可以适当更改 目录结构 - compose 新建,线上环境配置 - data - conf - node_modules - static - docker-compose.yml - docker-compose-prod.yml 新建

简要的线上环境部署概览

谈到线上环境,一般开发同学,不太容易接触到.即使接触到,也只是其中的冰山一角! 所以,其实说起线上环境的部署,咱们好像都有点懂,但是又都不一定完全懂!网上的知识无穷无尽,但往往都是各司一职,对于普通同学,很难窥其全貌! 所以,我今天就来说说,一些普通的线上环境的部署步骤,和一些脚本小技巧吧.只希望通过这篇文章,能够让大家有一个运维的全局! 我将会分几条线来整理咱们的运维思路! 一.从理论上讲,我们应该怎么做? 1. 针对的是什么样的用户群体,体量大量会有多少? 这是一个部署规划的前题.为啥呢?

rsync实现负载均衡集群文件同步,搭建线上测试部署环境

闲来无事,搭建一个负载均衡集群,至于负载均衡集群搭建过程,找时间写下.这次主要写集群之间的文件同步,以及线上测试环境的搭建. 笔者看过很多公司都没有线上测试环境,真是崩溃了,不造怎么确保线上线下环境一致的. 笔者此次使用三台服务器: 192.168.138.3   web服务器 192.168.138.4   web服务器 192.168.138.10  web服务器+线上测试环境+源站 其中3 4 服务器作为集群中的web服务器,对外开放,是负载均衡集群的部分. 其中10 服务器不对外开放,代

使用Fabric批量部署上线和线上环境监控

本文讲述如何使用fabric进行批量部署上线的功能 这个功能对于小应用,可以避免开发部署上线的平台,或者使用linux expect开发不优雅的代码. 前提条件: 1.运行fabric脚本的机器和其他机器tcp_port=22端口通 2.ssh可以登录,你有账号密码 一.先说批量部署上线 先上代码,再仔细讲解,脚本如下 # -*- coding:utf-8 -*- from fabric.colors import * from fabric.api import * from contextl

express框架开发接口部署线上环境PM2

1.PM2介绍 PM2是一个线上环境下,用于启动nodejs进程守护的工具,用来保证服务的稳定及分摊服务器进程和压力. 2.下载安装 npm install pm2 -g  => pm2 --version  => 在package.json scripts中配置 "prd": "cross-env NODE_ENV=production pm2 start app.js" =>  npm run prd运行,运行结果如下图: 3.常用命令 启动:

Node.js线上服务器部署与发布

第1章 课程预热对整个部署思路进行全流程介绍,通过 5 个不同类型项目,来演示从本地的仓库到最终线上稳定运行的整个项目部署发布流程,来帮助始终编程在一线的前端或者后端工程师,甚至是有 Coding 能力的产品经理,从操作流程和架构形态上,掌握从零开始的项目上线环节,掌握这关键一步,跨过去前端到后端,本地到线上,开发到生产...1-1 为什么是全栈最后一公里1-2 搭建线上生产环境需要做什么 第2章 待部署的 5 个本地 Nodejs 项目分别介绍五个技术架构和产品形态的项目背景,一个 Nodej

Netty简单应用与线上服务器部署_netty视频

Netty简单应用与线上服务器部署 课程学习地址:http://www.xuetuwuyou.com/course/198 课程出自学途无忧网:http://www.xuetuwuyou.com 一.开发环境 4.1.11.Final   jdk1.8 maven 3.2 Spring 4.3.9 二.适合人群 ①想深入学习java ClassLoader ②想在线上linux服务器上运行netty或Springboot服务 三.课程目标 ①掌控ClassLoader ②学会编写shell脚本

线上环境的回滚机制

[场景描述]你是否遇到过这种情况,在正常运行的线上环境下要要重新发布一个项目, [正常的操作如下]: 1.先把tomcat关掉: 2.删掉tomcat下的项目文件(按需备份),把war包放在tomcat对应正确路径下解压: 3.重启tomcat,重启后发现部署失败代码有问题则执行4,否则结束. 4.部署出错,赶紧关闭tomcat,把上一个版本/备份拷回来,再重启tomcat,结束.... 是不是觉得太low?这里tomcat关闭重启的时间太长了,并且有可能要来回拷贝解压两次~!不能忍,来巧妙使用

Nodejs线上日志部署

Nodejs 被越来越多的使用到线上系统中,但线上系统没有日志怎么行呢. 一.forever记录日志 我的线上系统使用forever来启动服务,最开始就直接使用了forever来记录 forever start -a -l ./logs/forever.log -a 表示追加日志文件      -l 指定日志文件 -s 忽略console.log输出的日志记录(使用log4j时要用这个) 最开始还挺好的,所有日志都能记录下来,但是既然是线上环境,日志比较多,跑着跑着就出问题了. forever.