自管理部署的生产说明
本页详细介绍了影响 MongoDB 的系统配置(尤其是在生产环境中运行时)。
注意
要了解有关针对 MongoDB Atlas 中托管的部署而在生产环境中运行的更多信息,请参阅 Atlas Production 说明。
平台支持
要在生产环境中运行,请参阅推荐的平台以获取操作系统建议。
平台支持说明
x86_64
MongoDB 需要满足以下最低配置要求的 x86_64
微架构:
对于 Intel
x86_64
,MongoDB 需要:Sandy Bridge 或更高版本的酷睿处理器,再或
Tiger Lake 或更高版本的赛扬或奔腾处理器。
对于 AMD
x86_64
,MongoDB 需要:Bulldozer 或更高版本的处理器。
从 MongoDB 5.0 开始,mongod
、mongos
和旧版 mongo
Shell 不再支持不符合此最低微架构要求的 x86_64
平台。
MongoDB 仅支持运行 Red Hat Compatible Kernel (RHCK) 的 Oracle Linux。MongoDB 不支持 Unbreakable Enterprise Kernel (UEK)。
MongoDB 5.0 需要使用 AVX 指令集,该指令集在部分 Intel 和 AMD 处理器上可用。
arm64
arm64
上的 MongoDB 需要ARMv8.2-A或后来的微架构。
从 MongoDB 5.0 开始,mongod
、mongos
和旧版 mongo
Shell 不再支持不符合此最低微架构要求的 arm64
平台。
要使用 ARM v8.4-A 或更高版本的微架构,请使用 MongoDB 版本 7.0 或更高版本。
注意
MongoDB 不再支持缺乏正确 CPU 架构的单板硬件 (Raspberry Pi 4)。如需了解更多信息,请参阅 MongoDB 5.0 中的兼容性变更。
平台支持矩阵
从 MongoDB 8.0 开始,新的 MongoDB Server 版本(主要版本和次要版本)支持操作系统(OS)供应商定义的最低操作系统次要版本。当操作系统供应商不再支持某个操作系统次要版本之后,MongoDB 会更新 MongoDB Server,以支持下一个操作系统次要版本。有关详细信息,请参阅 MongoDB 平台支持改进。
MongoDB 8.0 支持以下最低操作系统次要版本:
Red Hat Enterprise Linux 8.8
Red Hat Enterprise Linux 9.3
SUSE Linux Enterprise Server 15 SP5
Amazon Linux 2023 版本 2023.3
重要
v4.4 生命周期结束
V4.4 已于 2024 年 2 月 29 日到期,MongoDB 不再提供支持。
平台 | 架构 | 版本 | 8.0 | 7.0 | 6.0 | 5.0 | 4.4 |
---|---|---|---|---|---|---|---|
Amazon Linux 2023 | x86_64 | Enterprise | ✓ | ✓ | |||
Amazon Linux 2023 | x86_64 | Community | ✓ | ✓ | |||
Amazon Linux V2 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | |
Amazon Linux V2 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
Debian 12 | x86_64 | Enterprise | ✓ | ✓ | |||
Debian 12 | x86_64 | Community | ✓ | ✓ | |||
Debian 11 | x86_64 | Enterprise | ✓ | ✓ | 5.0.8+ | ||
Debian 11 | x86_64 | Community | ✓ | ✓ | 5.0.8+ | ||
Debian 10 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ||
Debian 10 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Debian 9 | x86_64 | Enterprise | ✓ | ✓ | |||
Debian 9 | x86_64 | Community | ✓ | ✓ | |||
RHEL/Rocky/Alma/Oracle Linux 9.0+ [1] | x86_64 | Enterprise | ✓ | ✓ | 6.0.4+ | ||
RHEL/Rocky/Alma/Oracle Linux 9.0+ [1] | x86_64 | Community | ✓ | ✓ | 6.0.4+ | ||
RHEL/Rocky/Alma/Oracle Linux 8.0+ [1] | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | ✓ |
RHEL/Rocky/Alma/Oracle Linux 8.0+ [1] | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
RHEL/CentOS/Oracle Linux 7.0+ [1] | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | |
RHEL/CentOS/Oracle Linux 7.0+ [1] | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
RHEL/CentOS/Oracle Linux 6.2+ [1] | x86_64 | Enterprise | ✓ | ||||
RHEL/CentOS/Oracle Linux 6.2+ [1] | x86_64 | Community | ✓ | ||||
SLES 15 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | ✓ |
SLES 15 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
SLES 12 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | |
SLES 12 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
Ubuntu 24.04 | x86_64 | Enterprise | ✓ | ||||
Ubuntu 24.04 | x86_64 | Community | ✓ | ||||
Ubuntu 22.04 | x86_64 | Enterprise | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 22.04 | x86_64 | Community | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 20.04 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 20.04 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 18.04 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ||
Ubuntu 18.04 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Ubuntu 16.04 | x86_64 | Enterprise | ✓ | ||||
Ubuntu 16.04 | x86_64 | Community | ✓ | ||||
Windows 11 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ||
Windows 11 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Windows Server 2022 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ||
Windows Server 2022 | x86_64 | Community | ✓ | ✓ | ✓ | ||
Windows Server 2019 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ✓ | |
Windows Server 2019 | x86_64 | Community | ✓ | ✓ | ✓ | ✓ | |
Windows 10 / Server 2016 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ||
Windows 10 / Server 2016 | x86_64 | Community | ✓ | ✓ | ✓ | ||
macOS 14 | x86_64 | Enterprise | ✓ | ||||
macOS 14 | x86_64 | Community | ✓ | ||||
macOS 13 | x86_64 | Enterprise | ✓ | ✓ | |||
macOS 13 | x86_64 | Community | ✓ | ✓ | |||
macOS 12 | x86_64 | Enterprise | ✓ | ✓ | |||
macOS 12 | x86_64 | Community | ✓ | ✓ | |||
macOS 11 | x86_64 | Enterprise | ✓ | ✓ | |||
macOS 11 | x86_64 | Community | ✓ | ✓ | |||
macOS 10.15 | x86_64 | Enterprise | ✓ | ✓ | ✓ | ||
macOS 10.15 | x86_64 | Community | ✓ | ✓ | ✓ | ||
macOS 10.14 | x86_64 | Enterprise | ✓ | ✓ | |||
macOS 10.14 | x86_64 | Community | ✓ | ✓ | |||
macOS 10.13 | x86_64 | Enterprise | ✓ | ||||
macOS 10.13 | x86_64 | Community | ✓ | ||||
macOS 14 | arm64 | Enterprise | ✓ | ||||
macOS 14 | arm64 | Community | ✓ | ||||
macOS 13 | arm64 | Enterprise | ✓ | ✓ | |||
macOS 13 | arm64 | Community | ✓ | ✓ | |||
macOS 12 | arm64 | Enterprise | ✓ | ✓ | |||
macOS 12 | arm64 | Community | ✓ | ✓ | |||
macOS 11 | arm64 | Enterprise | ✓ | ✓ | |||
macOS 11 | arm64 | Community | ✓ | ✓ | |||
Amazon Linux 2023 | arm64 | Enterprise | ✓ | ✓ | |||
Amazon Linux 2023 | arm64 | Community | ✓ | ✓ | |||
Amazon Linux 2 | arm64 | Enterprise | ✓ | ✓ | ✓ | 4.4.4+ | |
Amazon Linux 2 | arm64 | Community | ✓ | ✓ | ✓ | 4.4.4+ | |
RHEL/CentOS/Rocky/Alma 9 | arm64 | Enterprise | ✓ | ✓ | ✓ | ||
RHEL/CentOS/Rocky/Alma 9 | arm64 | Community | ✓ | ✓ | ✓ | ||
RHEL/CentOS/Rocky/Alma 8 | arm64 | Enterprise | ✓ | ✓ | ✓ | ✓ | 4.4.4+ |
RHEL/CentOS/Rocky/Alma 8 | arm64 | Community | ✓ | ✓ | ✓ | ✓ | 4.4.4+ |
Ubuntu 24.04 | arm64 | Enterprise | ✓ | ||||
Ubuntu 24.04 | arm64 | Community | ✓ | ||||
Ubuntu 22.04 | arm64 | Enterprise | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 22.04 | arm64 | Community | ✓ | ✓ | 6.0.4+ | ||
Ubuntu 20.04 | arm64 | Enterprise | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 20.04 | arm64 | Community | ✓ | ✓ | ✓ | ✓ | ✓ |
Ubuntu 18.04 | arm64 | Enterprise | ✓ | ✓ | ✓ | ||
Ubuntu 18.04 | arm64 | Community | ✓ | ✓ | ✓ | ||
Ubuntu 16.04 | arm64 | Enterprise | ✓ | ||||
RHEL/Rocky/Alma 8 [ 5 ] | ppc64le | Enterprise | ✓ | ✓ | ✓ | ✓ | ✓ |
RHEL/CentOS 7 | ppc64le | Enterprise | 6.0.7+ | ✓ | ✓ | ||
RHEL/Rocky/Alma 8 [ 5 ] | s390x | Enterprise | ✓ | ✓ | ✓ | 5.0.9+ | |
RHEL/CentOS 7 | s390x | Enterprise | ✓ | ✓ | ✓ | ||
RHEL/CentOS 7 | s390x | Community | ✓ | ✓ |
[1] | (1, 2, 3, 4, 5, 6, 7, 8) 在 Oracle Linux 上,MongoDB 仅支持 Red Hat Compatible Kernel。 |
[2] | MongoDB 版本 5.0 及更高版本针对 SLES 12 Service Pack 5 进行了测试。MongoDB 的早期版本针对不带服务包的 SLES 12 进行了测试。 |
[3] | MongoDB 版本 7.0 及更高版本针对 SLES 12 Service Pack 4 进行测试。早期版本的 MongoDB 针对不带服务包的 SLES 12 进行测试。 |
[4] | MongoDB 版本 7.0 针对 RHEL 7.9 进行构建和测试。早期版本的 MongoDB 针对 RHEL 7 进行测试,并假定支持向前兼容。 |
[5] | (1、2)PPC64LE 和 s390x 上的 RHEL 8 不支持 MongoDB 8.0 及更高版本中使用的 TCMalloc 更新版。在这些架构上,RHEL 8 使用旧版的 TCMalloc。要了解更多信息,请参阅用于自管理部署的 TCMalloc 性能优化。 |
[6] | PPC 64LE 上的 RHEL 9 不支持 MongoDB 8.0 及更高版本中使用的 TCMalloc 的更新版本。在此架构上,RHEL 9使用旧版 TCMalloc 版本。要了解更多信息,请参阅用于自管理部署的 TCMalloc 性能优化。 |
推荐平台
虽然 MongoDB 支持多种平台,但在 x86_64
架构的生产环境中建议使用以下操作系统:
Amazon Linux
Debian
RHEL [ 7 ]
SLES
Ubuntu LTS
Windows Server
为获得最佳效果,请运行平台的最新版本。如果运行的是旧版本,请确保其提供程序支持您的版本。
[7] | 针对 RHEL 版本 8.0+ 发布的 MongoDB 本地产品与 Rocky Linux 版本 8.0+ 和 AlmaLinux 版本 8.0+ 兼容,具体取决于这些发行版对提供 RHEL 完全兼容性的义务的履行情况。 |
使用最新的稳定版本软件包
确保您拥有最新的稳定版本。
MongoDB 版本可在 MongoDB 下载中心找到:
有关升级到最新次要发布的详细信息,请参阅升级到MongoDB最新的自我管理补丁版本。
MongoDB 下载中心还提供了以下相关软件包:
对于其他MongoDB产品,请参阅各自的文档。
MongoDB dbPath
dbPath
目录中的文件必须与配置的存储引擎相对应。 如果 dbPath
包含 --storageEngine
指定的存储引擎以外的存储引擎创建的数据文件,mongod
将无法启动。
mongod
必须具备指定 dbPath
的读写权限。
如果使用防病毒 (AV) 扫描程序或端点检测与响应 (EDR) 扫描程序,请将扫描程序配置为从扫描中排除 database storage path
和 database log path
。
database storage path
中的数据文件已压缩。此外,如果使用加密存储引擎,这些数据文件也会被加密。扫描这些文件的 I/O 和 CPU 成本可能会严重降低性能,同时不提供任何安全优势。
如不排除 database storage path
和 database log path
中的目录,扫描程序可能会隔离或删除重要文件。丢失或隔离的文件可能会损坏数据库并使 MongoDB 实例崩溃。
并发
WiredTiger
WiredTiger 支持读取者和写入者同时访问集合中的文档。客户端可在写入操作进行时读取文档,且多个线程可同时修改集合中的不同文档。
数据一致性
日记
MongoDB 对磁盘日志采用预写式日志方法。日志功能保证在 mongod
由于崩溃或其他严重故障而终止的情况下,MongoDB 可以快速恢复已写入日志但未写入数据文件的写入操作。请参阅日志,了解详情。
读关注 (read concern)
如果写入请求确认,您可以使用因果一致的会话来读取您自己的写入。
写关注
写关注描述了从 MongoDB 请求的写入操作确认级别。写关注的级别会影响返回写入操作的速度。当写入操作具有较弱 的写关注时,会迅速返回这些写入操作。当写关注较强 时,客户端在发送写入操作后必须等待,直到 MongoDB 在请求的写关注级别确认写入操作。由于写关注不足,写入操作可能在客户端看来已成功,但在某些服务器故障的情况下可能不会持久化。
有关为您的部署选择适当的写关注级别的更多信息,请参阅写关注文档。
网络
使用可信网络环境
务必在可信环境中运行 MongoDB,使用网络规则阻止来自所有未知计算机、系统和网络的访问。与任何依赖于网络访问的敏感系统一样,您的 MongoDB 部署应该只能由需要访问的特定系统访问,例如应用程序服务器、监控服务和其他 MongoDB 组件。
重要
默认情况下,authorization(授权)未启用,并且 mongod
假定环境可信。根据需要启用 authorization
模式。有关 MongoDB 支持的身份验证机制以及 MongoDB 授权的更多信息,请参阅自管理部署中的身份验证和自管理部署中基于角色的访问控制。
有关安全方面的其他信息和注意事项,请特别参阅安全部分的文档:
对于 Windows 用户,在 Windows 上部署 MongoDB 时,请考虑有关 TCP 配置的 Windows Server Technet 文章。
禁用 HTTP 接口
该 HTTP 接口默认禁用。请勿在生产环境中启用该 HTTP 接口。
管理连接池大小
调整连接池大小以适应您的使用案例,避免 mongod
或 mongos
实例的连接资源过载。从当前数据库请求典型数量的 110-115% 开始,根据需要修改连接池大小。请参阅连接池选项以了解如何调整连接池大小。
connPoolStats
命令返回有关分片集群中 mongos
和
mongod
实例与当前数据库的打开连接数量的信息。
另请参阅分配足够的 RAM 和 CPU。
硬件考虑因素
MongoDB 专门针对商用硬件而设计,几乎没有硬件要求或限制。MongoDB 的核心组件在小端硬件上运行,主要是 x86/x86_64 处理器。客户端库(即驱动程序)可以在大端或小端系统上运行。
分配足够的 RAM 和 CPU
至少应确保每个 mongod
或 mongos
实例能访问两个物理核心或一个多核物理 CPU。
WiredTiger
WiredTiger 存储引擎支持多线程,可以利用额外的 CPU 核心。具体来说,相对于可用 CPU 数量,活动线程(即并发操作)的总数可能会影响性能:
吞吐量随着并发活动操作数量增加而增加,最高可达 CPU 数量。
当同时活跃的操作数量超过 CPU 数量且超出的数量达到一定阈值时,吞吐量便会降低。
阈值取决于您的应用程序。您可以通过试验和测量吞吐量来确定应用程序的最佳并发活动操作数量。mongostat
的输出在 (ar|aw
) 列中提供了关于活动读取/写入数量的统计信息。
借助 WiredTiger,MongoDB 可同时利用 WiredTiger 内部缓存和文件系统缓存。
默认 WiredTiger 内部缓存大小为以下两者中的较大者:
(RAM 大小 - 1 GB)的 50%,或
256 MB.
例如,在总 RAM 为 4GB 的系统上,WiredTiger 缓存使用 1.5GB RAM (0.5 * (4 GB - 1 GB) =
1.5 GB
)。相反,在总 RAM 为 1.25GB 的系统上,WiredTiger 为 WiredTiger 缓存分配了 256 MB,因为这大于总 RAM 的一半减去 1 GB (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
)。
注意
在某些情况下,比如在容器中运行时,数据库的内存约束可以低于系统总内存。在此类情况下,将此内存限制而非系统总内存用作最大可用 RAM。
如需查看内存限制,请参阅 hostInfo.system.memLimitMB
。
默认情况下,WiredTiger 对所有集合使用 Snappy 区块压缩,对所有索引使用前缀压缩。压缩默认值可以在全局级别进行配置,也可以在集合和索引创建期间针对每个集合和每个索引进行设置。
WiredTiger 内部缓存和磁盘格式中的数据使用不同的表示形式:
文件系统缓存中的数据与磁盘上的数据格式相同,并且同样拥有数据文件压缩带来的好处。操作系统使用文件系统缓存来减少磁盘 I/O。
WiredTiger 内部缓存中加载的索引具有与磁盘上格式不同的数据表示形式,但仍可利用索引前缀压缩来减少 RAM 使用量。索引前缀压缩会对被索引字段中的常用前缀去重。
WiredTiger 内部缓存中的集合数据未压缩,并使用与磁盘上格式不同的表示形式。区块压缩可大幅节省磁盘上存储空间,但数据必须解压缩才能由服务器操作。
借助文件系统缓存,MongoDB 会自动使用 WiredTiger 缓存或其他进程未使用的所有空闲内存。
如需调整 WiredTiger 内部缓存大小,请参阅 storage.wiredTiger.engineConfig.cacheSizeGB
和 --wiredTigerCacheSizeGB
。避免将 WiredTiger 内部缓存大小增加到超过其默认值。
注意
storage.wiredTiger.engineConfig.cacheSizeGB
限制了 WiredTiger 内部缓存的大小。操作系统使用可用的空闲内存进行文件系统缓存,这允许压缩的 MongoDB 数据文件保留在内存中。此外,操作系统使用任何空闲 RAM 来缓冲文件系统块和文件系统缓存。
为了容纳额外的 RAM 用户,您可能必须减少 WiredTiger 的内部缓存大小。
默认 WiredTiger 内部缓存大小值假设每台计算机有一个 mongod
实例。如果一台机器包含多个 MongoDB 实例,则应减少该设置以容纳其他 mongod
实例。
如果您在某一容器(例如,lxc
、
cgroups
、Docker 等)中运行 mongod
,而这一容器无权访问系统中的全部可用 RAM,请将
storage.wiredTiger.engineConfig.cacheSizeGB
的值设置为小于容器中可用 RAM 数量的值。确切的数量取决于容器中运行的其他进程。请参阅 memLimitMB
。
要查看有关缓存和驱逐率的统计信息,请参阅 serverStatus
命令返回的 wiredTiger.cache
字段。
压缩和加密
使用加密时,配备 AES-NI 指令集扩展的 CPU 表现出显著的性能优势。如果您使用的是带有加密存储引擎的 MongoDB Enterprise,请选择支持 AES-NI 的 CPU 以获得更好的性能。
使用固态硬盘 (SSD)
MongoDB 在搭配 SATA SSD(固态硬盘)的情况下具有很好的效果以及出色的性价比。
如果可用且注重经济性,请使用固态硬盘 (SSD)。
商用 (SATA) 旋转驱动器通常是不错的选择,因为价格更昂贵的旋转驱动器提供的随机 I/O 性能提升并不明显(仅为 2 倍左右)。使用固态硬盘或增加 RAM 可能更有效地提高 I/O 吞吐量。
MongoDB 和 NUMA 硬件
在具有非统一内存访问 (NUMA) 的系统上运行 MongoDB 可能会导致许多操作问题,包括时段性的性能缓慢和系统进程使用率较高。
在 NUMA 硬件上运行 MongoDB 服务器和客户端时,应当配置内存交织策略,以便主机以非 NUMA 方式运行。当部署在 Linux(自版本 2.0 起)和 Windows(自版本 2.6 起)计算机上时,MongoDB 会在启动时检查 NUMA 设置。如果 NUMA 配置可能会降低性能,MongoDB 会打印警告消息。
numad
守护进程还会降低mongod
性能。 应确保 MongoDB 服务器上未启用numad
。
提示
另请参阅:
MySQL"swap insanity" 问题和 NUMA 的影响文章,介绍了 NUMA 对数据库的影响。这篇文章介绍了 NUMA 及其目标,并说明了这些目标如何与生产数据库不兼容。尽管该博客文章讨论的是 NUMA 对 MySQL 的影响,但 MongoDB 遇到的问题是相似的。
在 Windows 上配置 NUMA
在 Windows 上,必须通过计算机的 BIOS 启用内存交织。有关详细信息,请参阅您的系统文档。
在 Linux 上配置 NUMA
在 Linux 上,必须禁用区域回收,并确保您的 mongod
和 mongos
实例由 numactl
启动,这通常是通过平台的初始化系统配置的。您必须执行这两个操作以禁止将 NUMA 用于 MongoDB。
使用以下命令禁用区域回收:
echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode sudo sysctl -w vm.zone_reclaim_mode=0 确保
mongod
和mongos
由numactl
启动。这通常是通过平台的初始化系统配置的。运行以下命令以确定平台上正在使用的初始化系统:ps --no-headers -o comm 1 如果为
systemd
,则您的平台使用 systemd init 系统,并且您必须 按照下面的 systemd 标签页中的步骤来编辑 MongoDB 服务文件。如果为 "
init
",则您的平台使用 SysV Init 系统且无需执行此步骤。SysV Init 的默认 MongoDB 初始化脚本包括默认通过numactl
来启动 MongoDB 实例的必要步骤。如果您管理自己的初始化脚本(即不使用这些初始化系统中的任何一个),则必须按照下面 Custom init scripts(自定义初始化脚本)选项卡中的步骤来编辑您的自定义初始化脚本。
您必须使用
numactl
启动每个mongod
实例,包括所有配置服务器、mongos
实例和客户端。为每个实例编辑默认的 systemd 服务文件,如下所示:复制默认的 MongoDB 服务文件:
sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/ 编辑
/etc/systemd/system/mongod.service
文件,并将ExecStart
语句更新为以下方内容开头:/usr/bin/numactl --interleave=all 例子
如果您现有的
ExecStart
语句如下:ExecStart=/usr/bin/mongod --config /etc/mongod.conf 将该语句更新为:
ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf 将更改应用于
systemd
:sudo systemctl daemon-reload 重新启动任何正在运行的
mongod
实例:sudo systemctl stop mongod sudo systemctl start mongod 如果适用,对任何
mongos
实例重复上述步骤。
您必须使用
numactl
启动每个mongod
实例,包括所有配置服务器、mongos
实例和客户端。如果尚未安装,请为您的平台安装
numactl
。有关安装numactl
软件包的信息,请参阅操作系统的文档。配置每个自定义初始化脚本,通过
numactl
启动每个 MongoDB 实例:numactl --interleave=all <path> <options> 其中
<path>
是要启动的程序的路径,<options>
是要传递给该程序的任何可选参数。例子
numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf
请参阅 /proc/sys/vm/* 文档,了解详情。
磁盘和存储系统
Swap
在可避免交换或将交换保持在最低限度的情况下,MongoDB 性能最佳,因为从交换中检索数据总是比在 RAM 中访问数据慢。但是,如果托管 MongoDB 的系统耗尽 RAM,交换功能则可阻止 Linux OOM Killer 终止 mongod
进程。
一般来说,您应选择以下交换策略之一:
在您的系统上分配交换空间,并将内核配置为仅允许在高内存负载下进行交换,或是
请勿在系统上分配交换空间,并将内核配置为完全禁用交换
请参阅设置 vm.swappiness,了解在 Linux 系统上按照这些指南配置交换的说明。
注意
如果您的 MongoDB 实例托管在还运行其他软件(例如网络服务器)的系统上,则应选择第一个交换策略。在此情况下,请勿禁用交换。如果可能,强烈建议在自己的专用系统上运行 MongoDB。
RAID
为了在存储层方面获得最佳性能,请使用 RAID-10 支持的磁盘。RAID-5 和 RAID-6 通常无法提供足够的性能来支持 MongoDB 部署。
远程文件系统 (NFS)
使用 WiredTiger 存储引擎,如果远程文件系统符合 ISO/IEC 9945-1:1996 (POSIX.1),则 WiredTiger 对象可以存储在远程文件系统上。由于远程文件系统通常比本地文件系统慢,因此使用远程文件系统进行存储可能会降低性能。
如果决定使用 NFS,请将以下 NFS 选项添加到 /etc/fstab
文件中:
bg
hard
nolock
noatime
nointr
根据您的内核版本,其中一些值可能已设置为默认值。有关更多信息,请参阅您的平台文档。
将组件分离到不同存储设备
为了提高性能,请考虑根据应用程序的访问和写入模式将数据库的数据和日志分布存放到不同的存储设备上。将组件安装为单独的文件系统,并使用符号链接将每个组件的路径映射到存储它的设备。
对于 WiredTiger 存储引擎,您还可在其他存储设备上存储这些索引。请参阅 storage.wiredTiger.engineConfig.directoryForIndexes
。
注意
使用其他存储设备会影响创建数据快照式备份的能力,因为这些文件会位于不同的设备和卷上。
调度
虚拟设备或云托管设备的调度
对于通过虚拟机监控程序连接到虚拟机实例或由云托管提供商托管的本地区块设备,客户机操作系统应使用 cfq 调度器以获得最佳性能。cfq
调度器允许操作系统将 I/O 调度推迟到底层虚拟机监控程序。
注意
如果满足以下所有条件,则可使用 noop 调度器进行调度:
虚拟机监视器为 VMware。
使用副本集拓扑结构或分片集群。
虚拟机位于同一虚拟主机上。
包含 DBpaths 的底层存储是一个常见的 LUN 块存储。
调度物理服务器
对于物理服务器,操作系统应该使用截止时间调度程序。截止时间调度程序限制每个请求的最大延迟,并保持良好的磁盘吞吐量,这是磁盘密集型数据库应用程序的最佳选择。
架构
副本集
有关副本集部署的架构注意事项概述,请参阅副本集架构文档。
分片集群
请参阅分片集群生产架构,了解针对生产部署的建议分片集群架构。
压缩
WiredTiger 可以使用以下一种压缩库压缩集合数据:
- snappy
- 提供低于
zlib
或zstd
的压缩率,但 CPU 成本比二者均低。
- zlib
- 提供高于
snappy
的压缩率,但 CPU 成本高于snappy
和zstd
。
- zstd
- 提供高于
snappy
和zlib
的压缩率,且 CPU 成本低于zlib
。
默认情况下,WiredTiger 使用 snappy 压缩库。要更改压缩设置,请参阅 storage.wiredTiger.collectionConfig.blockCompressor
。
WiredTiger 默认对所有索引使用前缀压缩。
时钟同步
MongoDB 组件保持逻辑时钟,以支持时间相关的操作。使用 NTP 同步主机时钟可以降低组件之间时钟漂移的风险。组件之间的时钟漂移会增加时间相关操作出现错误或异常行为的可能性,例如:
如果任何给定 MongoDB 组件的底层系统时钟与同一部署中的其他组件偏差一年或更长时间,则这些节点之间的通信可能会变得不可靠或完全停止。
maxAcceptableLogicalClockDriftSecs
参数控制组件之间可接受的时钟漂移量。具有较低maxAcceptableLogicalClockDriftSecs
值的集群对时钟漂移的容忍度也相应地较低。两个具有不同系统时钟的集群成员,在执行返回当前集群或系统时间的操作时,如
Date()
、{ 5 }NOW
和CLUSTER_TIME
,可能会返回不同的值。
依赖计时的功能在集群中可能会出现不一致或不可预测的行为,并且 MongoDB 组件之间存在时钟漂移。
平台特定注意事项
Linux 上的 MongoDB
内核和文件系统
在 Linux 上的生产环境中运行 MongoDB 时,应使用Linux kernel 2.6.36 版本或更高版本,使用 XFS 或 EXT4 文件系统。尽可能使用 XFS,因为它通常在 MongoDB 中表现更好。
使用 WiredTiger 存储引擎时,强烈建议为数据承载节点使用 XFS,以避免将 EXT4 与 WiredTiger 结合使用时可能出现的性能问题。
一般来说,如果您使用 XFS 文件系统,请至少使用 Linux 内核版本
2.6.25
。如果使用 EXT4 文件系统,请至少使用 Linux 内核版本
2.6.28
。在 Red Hat Enterprise Linux 和 CentOS 上,至少应使用 Linux 内核版本
2.6.18-194
。
系统 C 库
MongoDB 在 Linux 上使用 GNU C 库 (glibc)。通常,每个 Linux 发行版都提供自己的经过审查的 C 库版本。为获得最佳结果,请使用此系统提供版本可用的最新更新。您可以使用系统的软件包管理器来检查是否已安装最新版本。例如:
在 RHEL / CentOS 上,以下命令会更新系统提供的 GNU C 库:
sudo yum update glibc 在 Ubuntu / Debian 上,以下命令会更新系统提供的 GNU C 库:
sudo apt-get install libc6
fsync()
用于目录
重要
MongoDB 需要的文件系统要能够在目录上 支持
fsync()
。例如,HGFS 和 Virtual Box 的共享文件夹不 支持此操作。
将 vm.swappiness
设置为 1
或 0
“Swappiness”是一个影响虚拟内存管理器行为的 Linux 内核设置。vm.swappiness
设置范围从 0
到 100
:值越大,它就越倾向于将内存页面交换到磁盘,而不是从 RAM 中删除页面。
0
的设置完全禁用交换 [8]。设置为
1
允许内核仅进行交换以避免内存不足问题。设为
60
可指示内核频繁交换到磁盘,也是众多 Linux 发行版上的默认值。设置为
100
将通知内核主动交换到磁盘。
在可以避免交换或将交换保持在最低限度的情况下,MongoDB 性能最佳。因此,您应根据应用程序需求和集群配置,将 vm.swappiness
设置为 1
或 0
。
注意
大多数系统和用户进程在 cgroup 中运行,默认情况下将 vm.swappiness
设置为 60
。如果运行的是 RHEL/CentOS,请将 vm.force_cgroup_v2_swappiness
设置为 1
,以确保指定的 vm.swappiness
值覆盖任何 cgroup 默认值。
[8] | 对于 3.5 之前的 Linux 内核版本或 2.6.32-303 之前的 RHEL / CentOS 内核版本,将 vm.swappiness 设置为 0 时,内核仍能在某些紧急情况下进行交换。 |
注意
如果 MongoDB 实例托管在还运行其他软件(例如网络服务器)的系统上,则应将 vm.swappiness
设置为 1
。如果可能,强烈建议在自己的专用系统上运行 MongoDB。
要检查系统上的当前交换设置,请运行:
cat /proc/sys/vm/swappiness 要更改系统上的交换状态,请执行以下操作:
编辑
/etc/sysctl.conf
文件并添加以下行:vm.swappiness = 1 运行如下命令以应用设置:
sudo sysctl -p
注意
如果正在运行 RHEL/CentOS 并使用tuned
性能配置文件,则还必须编辑所选配置文件以将 vm.swappiness
设置为 1
或 0
。
建议配置
对于所有 MongoDB 部署:
使用网络时间协议 (NTP) 在主机之间同步时间。这在分片集群中尤其重要。
对于 WiredTiger 存储引擎,请考虑以下建议:
关闭包含数据库文件
的存储卷的
atime
。根据 ulimit
参考中的建议,调整平台的
ulimit
设置。当重度使用时,较低的ulimit
值会对 MongoDB 产生负面影响,并可能导致与 MongoDB 进程的连接失败和服务丢失。注意
如果打开文件数的
ulimit
值低于64000
,MongoDB 会生成初创企业警告。如果您正在运行 MongoDB 8.0,请启用透明大页面。
如果您正在运行 MongoDB 7.0 或更早版本,请禁用透明大页面。在早期版本中,MongoDB 在使用典型(4096 字节)虚拟内存页面时性能更好。
在 BIOS 中禁用 NUMA。如果不可行,请参阅 NUMA 硬件上的 MongoDB。
如果不使用默认 MongoDB 目录路径或端口,请为 MongoDB 配置 SELinux。
注意
如果使用 SELinux,任何需要服务器端 JavaScript 的 MongoDB 操作都会导致“segfault”错误。禁用 JavaScript 的服务器端执行描述了如何禁用服务器端 JavaScript 的执行。
对于 WiredTiger 存储引擎:
无论存储介质类型(旋转磁盘、SSD 等)为何,均应将预读大小设为 8 到 32 之间。
更高的预读通常有利于顺序 I/O 操作。由于 MongoDB 磁盘访问模式通常是随机的,因此使用更高的预读设置的好处有限,或者可能会导致性能下降。因此,除非测试表明更高的预读值具有可测量、可重复且可靠的优势,否则为了获得最佳的 MongoDB 性能,请将预读值设置在 8 到 32 之间。MongoDB 商业支持部门可提供有关备用预读配置的建议和指导。
MongoDB 和 TLS/SSL 库
在 Linux 平台上,您可能会在 MongoDB 日志中看到以下语句之一:
<path to TLS/SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod) <path to TLS/SSL libs>/libcrypto.so.<version>: no version information available (required by /usr/bin/mongod)
这些警告表明,系统的 TLS/SSL 库与编译 mongod
所针对的 TLS/SSL 库不同。通常,这些消息不需要干预;但是,您可以使用以下操作来确定 mongod
期望的符号版本:
objdump -T <path to mongod>/mongod | grep " SSL_" objdump -T <path to mongod>/mongod | grep " CRYPTO_"
这些操作将返回类似于以下行之一的输出:
0000000000000000 DF *UND* 0000000000000000 libssl.so.10 SSL_write 0000000000000000 DF *UND* 0000000000000000 OPENSSL_1.0.0 SSL_write
此输出中的最后两个字符串是符号版本和符号名称。将这些值与以下操作返回的值进行比较,以检测符号版本不匹配情况:
objdump -T <path to TLS/SSL libs>/libssl.so.1* objdump -T <path to TLS/SSL libs>/libcrypto.so.1*
此过程既不精确也不详尽:libcrypto
库中
mongod
使用的很多符号均未以
CRYPTO_
开头。
Windows 上的 MongoDB
对于使用 WiredTiger 存储引擎的 MongoDB 实例,Windows 上的性能与 Linux 上的性能相当。
虚拟环境中的 MongoDB
本部分介绍在一些比较常见的虚拟环境中运行 MongoDB 时的注意事项。
对于所有平台,请考虑安排。
AWS EC2
可考虑两种性能配置:
性能测试或基准测试的可重现性能,以及
原始最高性能
要为任一配置在 EC2 上调优性能,您应该:
如果您更关注 EC2 上的可重现性能,则还应该:
将预配 IOPS 用于存储,并使用单独的设备存储日志和数据。请勿使用为大多数实例类型提供的临时(固态硬盘)存储,因为它们的性能会动态变化。(
i
系列虽不在此列,但非常昂贵。)禁用 DVFS 和 CPU 省电模式。
禁用超线程。
使用
numactl
将内存局部性绑定到单个套接字。
AZURE
使用高级存储。Microsoft Azure 提供两种通用存储类型:标准存储和高级存储。相比标准存储,Azure 上的 MongoDB 使用高级存储时性能更好。
默认情况下,Azure 负载均衡器上的 TCP 空闲超时为 240 秒,而一旦 Azure 系统上的 TCP keepalive 大于该值,就可能导致该负载均衡器以静默方式断开连接。您应该将 tcp_keepalive_time
设置为 120 以改善此问题。
要在 Linux 上查看 keepalive 设置,请使用以下命令之一:
sysctl net.ipv4.tcp_keepalive_time 或者:
cat /proc/sys/net/ipv4/tcp_keepalive_time 该值以秒为单位。
注意
尽管该设置名称包含
ipv4
,但tcp_keepalive_time
值会同时应用于 IPv4 和 IPv6。要更改
tcp_keepalive_time
值,可使用以下命令之一,并提供以秒为单位的 <值>:sudo sysctl -w net.ipv4.tcp_keepalive_time=<value> 或者:
echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time 这些操作不会在系统重启后持续存在。要保留该设置,请将以下行添加到
/etc/sysctl.conf
,提供以秒为单位的 <value>,然后重启计算机:net.ipv4.tcp_keepalive_time = <value> 在
mongod
和
mongos
套接字上,大于300
秒(5 分钟)的 keepalive 值将被覆盖,并设置为
300
秒。
要在 Windows 上查看 keepalive 设置,请发出以下命令:
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime 默认情况下,该注册表值不存在。如果该值不存在,则会使用系统默认值,即
7200000
毫秒或采用十六进制的0x6ddd00
。要更改
KeepAliveTime
值,请在管理员 Command Prompt 中使用以下命令,其中<value>
以十六进制表示(例如120000
表示0x1d4c0
):reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value> Windows 用户应查看有关 KeepAliveTime 的 Windows Server Technet 文章,了解有关在 Windows 系统上为 MongoDB 部署设置 keepalive 的更多信息。大于或等于 600000 毫秒(10 分钟)的 keepalive 值将被
mongod
和mongos
忽略。
VMware
MongoDB 与 VMware 兼容。
VMware 支持内存复用,因而可为虚拟机分配比物理机可用内存更多的内存。当内存超量时,虚拟机监控程序会在各虚拟机之间重新分配内存。VMware 的气球驱动程序 (vmmemctl
) 会回收被视为价值最低的页面。
气球驱动程序驻留在客户机操作系统中。在某些配置下,当气球驱动程序扩展时,它可能会干扰 MongoDB 的内存管理并影响 MongoDB 的性能。
为了防止气球驱动程序和内存过量承诺功能对性能产生负面影响,请为运行 MongoDB 的虚拟机保留全部内存量。为虚拟机预留适当数量的内存,可以防止本地操作系统中的气球在管理程序存在内存压力时膨胀。
即使气球驱动程序和内存过量使用功能在某些配置下可能对 MongoDB 性能产生负面影响,也不要禁用这些功能。如果禁用这些功能,虚拟机管理程序可能会使用其交换空间来满足内存请求,从而对性能产生负面影响。
设置 VMware 的关联性规则,确保将虚拟机保留在特定 ESX/ESXi 主机上。如果必须手动将虚拟机迁移到另一台主机,并且虚拟机上的 mongod
实例是主实例,则必须先 step down
主实例,然后再 shut down the instance
。
请遵循 vMotion 和 VMKernel 的联网最佳实践。不遵循最佳实践可能导致性能问题,并影响副本集和分片集群的高可用性机制。
您可以克隆运行 MongoDB 的虚拟机。您可以使用此功能部署新的虚拟主机,将其添加为副本集的成员。
KVM
MongoDB 与 KVM 兼容。
KVM 支持内存复用,因而可以为虚拟机分配比物理机可用内存更多的内存。当内存超量时,虚拟机监控程序会在各虚拟机之间重新分配内存。KVM 的气球驱动程序会回收被视为价值最低的页面。
气球驱动程序驻留在客户机操作系统中。在某些配置下,当气球驱动程序扩展时,它可能会干扰 MongoDB 的内存管理并影响 MongoDB 的性能。
为了防止气球驱动程序和内存过量承诺功能对性能产生负面影响,请为运行 MongoDB 的虚拟机保留全部内存量。为虚拟机预留适当数量的内存,可以防止本地操作系统中的气球在管理程序存在内存压力时膨胀。
即使气球驱动程序和内存过量使用功能在某些配置下可能对 MongoDB 性能产生负面影响,也不要禁用这些功能。如果禁用这些功能,虚拟机管理程序可能会使用其交换空间来满足内存请求,从而对性能产生负面影响。
性能监测
iostat
在 Linux 上,使用 iostat
命令可检查磁盘 I/O 是否是数据库的瓶颈。运行 iostat 时应指定秒数,以避免显示涵盖服务器启动以来的时间的统计信息。
例如,以下命令将显示扩展统计信息以及每个显示报告的时间,流量以 MB/s 为单位,间隔时间为一秒:
iostat -xmt 1
iostat
中的关键字段:
%util
:这是快速检查时最有用的字段,表示设备/驱动程序正在使用的时间百分比。avgrq-sz
:平均请求大小。此值的数字越小,则表示随机 I/O 操作越多。
bwm-ng
bwm-ng 是一个用于监控网络使用情况的命令行工具。如果怀疑存在基于网络的瓶颈,可以使用 bwm-ng
开始诊断过程。
备份
要对您的 MongoDB 数据库进行备份,请参阅 MongoDB 备份方法概述。