This page details system configurations that affect MongoDB, especially when running in production.此页面详细介绍了影响MongoDB的系统配置,特别是在生产环境中运行时。
Note
MongoDB Atlas is a cloud-hosted database-as-a-service. If you can leverage public clouds, Atlas automatically addresses many of the considerations present in these Production Notes, as well as offering the following benefits:是一种云托管的数据库即服务。如果您可以利用公共云,Atlas会自动解决这些生产说明中存在的许多问题,并提供以下好处:
Security:安全:Atlas reduces configuration required for security features like encryption, auditing, and role-based access control.Atlas减少了加密、审计和基于角色的访问控制等安全功能所需的配置。- Scalability:
You can automatically scale your Atlas cluster based on usage. You can also configure granular scaling for compute, IOPS, and storage.您可以根据使用情况自动扩展Atlas集群。您还可以为计算、IOPS和存储配置粒度扩展。 Availability:可利用性:Atlas has a 99.995% uptime SLA. You can also configure multi-region and multi-cloud deployments with automated failover and continuous backups.Atlas的正常运行时间SLA为99.995%。您还可以通过自动故障转移和连续备份配置多区域和多云部署。Performance:性能You can use built-in tools like Query Insights and Performance Advisor to optimize performance, improve database operations, and manage costs.您可以使用Query Insights和Performance Advisor等内置工具来优化性能、改进数据库操作和管理成本。Full Text Search:全文搜索:You can build performant, relevance-based search functionality into your Atlas application.您可以在Atlas应用程序中构建高性能、基于相关性的搜索功能。
For more information, see the Atlas documentation and Atlas Production Notes.有关更多信息,请参阅Atlas文档和Atlas生产说明。
Platform Support平台支持
For running in production, refer to the Recommended Platforms for operating system recommendations.对于在生产环境中运行,请参阅操作系统建议的推荐平台。
Platform Support Notes平台支持说明
x86_64
MongoDB requires the following minimum MongoDB要求以下最低x86_64 microarchitectures:x86_64微体系结构:
For Intel对于Intelx86_64, MongoDB requires one of:x86_64,MongoDB需要以下之一:a Sandy Bridge or later Core processor, orSandy Bridge或更高版本的Core处理器,或a Tiger Lake or later Celeron or Pentium processor.Tiger Lake或更高版本的赛扬或奔腾处理器。
For AMD对于AMD x86_64,MongoDB需要:x86_64, MongoDB requires:a Bulldozer or later processor.推土机或更高版本的处理器。
Starting in MongoDB 5.0, 从MongoDB 5.0开始,mongod, mongos, and the legacy mongo shell no longer support x86_64 platforms which do not meet this minimum microarchitecture requirement.mongod、mongos和遗留的mongo shell不再支持不符合此最低微架构要求的x86_64平台。
MongoDB only supports Oracle Linux running the Red Hat Compatible Kernel (RHCK). MongoDB does not support the Unbreakable Enterprise Kernel (UEK).MongoDB只支持运行红帽兼容内核(RHCK)的Oracle Linux。MongoDB不支持Unbreakable Enterprise Kernel(UEK)。MongoDB 5.0 requires use of the AVX instruction set, available on select Intel and AMD processors.MongoDB 5.0需要使用AVX指令集,可在选定的Intel和AMD处理器上使用。
ARM64
MongoDB on arm64 requires the ARMv8.2-A or later microarchitecture.arm64上的MongoDB需要ARMv8.2-A或更高版本的微架构。
Starting in MongoDB 5.0, 从MongoDB 5.0开始,mongod, mongos, and the legacy mongo shell no longer support arm64 platforms which do not meet this minimum microarchitecture requirement.mongod、mongos和遗留的mongo shell不再支持不符合最低微架构要求的arm64平台。
To use the ARM v8.4-A or later microarchitecture, use MongoDB version 7.0 or later.要使用ARM v8.4-A或更高版本的微架构,请使用MongoDB 7.0或更高版。
Note
MongoDB no longer supports single board hardware lacking the proper CPU architecture (Raspberry Pi 4). MongoDB不再支持缺乏适当CPU架构的单板硬件(Raspberry Pi 4)。See Compatibility Changes in MongoDB 5.0 for more information.
Platform Support Matrix平台支持矩阵
Starting in MongoDB 8.0, new MongoDB Server versions (major and minor) support the minimum operating system (OS) minor version defined by the OS vendor. 从MongoDB 8.0开始,新的MongoDB Server版本(主要和次要)支持操作系统供应商定义的最低操作系统(OS)次要版本。After an OS minor version is no longer supported by the OS vendor, MongoDB updates the MongoDB Server to support the next OS minor version. 在操作系统供应商不再支持某个操作系统次要版本后,MongoDB会更新MongoDB服务器以支持下一个操作系统较小版本。For details, see MongoDB Platform Support Improvements.有关详细信息,请参阅MongoDB平台支持改进。
MongoDB 8.0 supports the following minimum OS minor versions:MongoDB 8.0支持以下最低操作系统次要版本:
Red Hat Enterprise Linux 8.8红帽企业Linux 8.8Red Hat Enterprise Linux 9.3红帽企业Linux 9.3SUSE Linux Enterprise Server 15 SP5SUSE Linux企业服务器15 SP5Amazon Linux 2023 version 2023.3亚马逊Linux 2023版本2023.3
Important
v6.0 End of Life
v6.0 reached end of life on July 31, 2025 and is no longer supported by MongoDB.v6.0于2025年7月31日达到生命周期终点,不再受MongoDB支持。
| 8.0 | 7.0 | |||
|---|---|---|---|---|
| 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 | ✓ | |
| Debian 11 | x86_64 | Community | ✓ | |
| RHEL/Rocky/Alma/Oracle Linux 9.0+ [1] | x86_64 | Enterprise | ✓ | ✓ |
| RHEL/Rocky/Alma/Oracle Linux 9.0+ [1] | x86_64 | Community | ✓ | ✓ |
| RHEL/Rocky/Alma/Oracle Linux 8.0+ [1] | x86_64 | Enterprise | ✓ | ✓ |
| RHEL/Rocky/Alma/Oracle Linux 8.0+ [1] | x86_64 | Community | ✓ | ✓ |
| RHEL/Oracle Linux 7.0+ [1] | x86_64 | Enterprise | ✓ | |
| RHEL/Oracle Linux 7.0+ [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 | ✓ | ✓ |
| Ubuntu 22.04 | x86_64 | Community | ✓ | ✓ |
| Ubuntu 20.04 | x86_64 | Enterprise | ✓ | ✓ |
| Ubuntu 20.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 | ✓ | |
| 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 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 | ✓ | |
| Amazon Linux 2 | arm64 | Community | ✓ | |
| RHEL/Rocky/Alma 9 | arm64 | Enterprise | ✓ | ✓ |
| RHEL/Rocky/Alma 9 | arm64 | Community | ✓ | ✓ |
| RHEL/Rocky/Alma 8 | arm64 | Enterprise | ✓ | ✓ |
| RHEL/Rocky/Alma 8 | arm64 | Community | ✓ | ✓ |
| Ubuntu 24.04 | arm64 | Enterprise | ✓ | |
| Ubuntu 24.04 | arm64 | Community | ✓ | |
| Ubuntu 22.04 | arm64 | Enterprise | ✓ | ✓ |
| Ubuntu 22.04 | arm64 | Community | ✓ | ✓ |
| Ubuntu 20.04 | arm64 | Enterprise | ✓ | ✓ |
| Ubuntu 20.04 | arm64 | Community | ✓ | ✓ |
| RHEL/Rocky/Alma 9 [6] | ppc64le | Enterprise | 8.0.7+ | |
| RHEL/Rocky/Alma 8 [5] | ppc64le | Enterprise | ✓ | ✓ |
| RHEL/Rocky/Alma 9 | s390x | Enterprise | 8.0.7+ | 7.0.20+ |
| RHEL/Rocky/Alma 8 [5] | s390x | Enterprise | ✓ | ✓ |
| [1] | (1, 2, 3, 4, 5, 6) |
| [2] |
| [3] | |
| [4] | |
| [5] | (1, 2) |
| [6] | |
Recommended Platforms推荐平台
While MongoDB supports a variety of platforms, the following operating systems are recommended for production use on 虽然MongoDB支持多种平台,但建议在x86_64 architecture:x86_64架构上使用以下操作系统进行生产:
- Amazon Linux
- Debian
- RHEL [7]
- SLES
- Ubuntu LTS
- Windows Server
For best results, run the latest version of your platform. If you run an older version, make sure that your version is supported by its provider.为了获得最佳效果,请运行最新版本的平台。如果您运行的是旧版本,请确保版本得到其提供商的支持。
| [7] | |
Use the Latest Stable Packages使用最新的稳定软件包
Be sure you have the latest stable release.确保你有最新的稳定版本。
MongoDB releases are available on the MongoDB Download Center:MongoDB版本可在MongoDB下载中心获得:
For details on upgrading to the most current minor release, see Upgrade to the Latest Self-Managed Patch Release of MongoDB.有关升级到最新次要版本的详细信息,请参阅升级到MongoDB的最新自我管理补丁版本。
The following related packages are also available on the MongoDB Download Center:以下相关软件包也可在MongoDB下载中心获得:
For other MongoDB products, see their respective documentation.有关其他MongoDB产品,请参阅其各自的文档。
MongoDB dbPath
The files in the dbPath directory must correspond to the configured storage engine. dbPath目录中的文件必须与配置的存储引擎相对应。如果mongod will not start if dbPath contains data files created by a storage engine other than the one specified by --storageEngine.dbPath包含由非--storageEngine指定的存储引擎创建的数据文件,mongod将不会启动。
mongod must possess read and write permissions for the specified 必须拥有指定dbPath.dbPath的读写权限。
If you use an antivirus (AV) scanner or an endpoint detection and response (EDR) scanner, configure your scanner to exclude the 如果使用防病毒(AV)扫描程序或端点检测和响应(EDR)扫描程序,请将扫描程序配置为从扫描中排除数据库存储路径和数据库日志路径。database storage path and the database log path from the scan.
The data files in the 数据库存储路径中的数据文件被压缩。database storage path are compressed. Additionally, if you use the encrypted storage engine, the data files are also encrypted. 此外,如果使用加密存储引擎,数据文件也会被加密。The I/O and CPU costs to scan these files may significantly decrease performance without providing any security benefits.扫描这些文件的I/O和CPU成本可能会显著降低性能,而不会提供任何安全优势。
If you don't exclude the directories in your 如果不排除数据库存储路径和数据库日志路径中的目录,扫描程序可能会隔离或删除重要文件。database storage path and database log path, the scanner could quarantine or delete important files. Missing or quarantined files can corrupt your database and crash your MongoDB instance.丢失或隔离的文件可能会损坏数据库并导致MongoDB实例崩溃。
Concurrency并发
WiredTiger
WiredTiger supports concurrent access by readers and writers to the documents in a collection. 支持读者和作者同时访问集合中的文档。Clients can read documents while write operations are in progress, and multiple threads can modify different documents in a collection at the same time.客户端可以在写入操作进行时读取文档,多个线程可以同时修改集合中的不同文档。
Tip
Allocate Sufficient RAM and CPU provides information about how WiredTiger takes advantage of multiple CPU cores and how to improve operation throughput.分配足够的RAM和CPU提供了有关WiredTiger如何利用多个CPU内核以及如何提高操作吞吐量的信息。
Data Consistency数据一致性
Journaling日志记录
MongoDB uses write ahead logging to an on-disk journal. MongoDB使用预写日志记录到磁盘日志中。Journaling guarantees that MongoDB can quickly recover write operations that were written to the journal but not written to data files in cases where 日志保证MongoDB可以在mongod terminated due to a crash or other serious failure. mongod因崩溃或其他严重故障而终止的情况下快速恢复写入日志但未写入数据文件的写入操作。See Journaling for more information.有关更多信息,请参阅日志。
Read Concern读取关注
You can use causally consistent sessions to read your own writes, if the writes request acknowledgment.如果写入请求确认,您可以使用因果一致的会话来读取自己的写入。
Write Concern写关注
Write Concern describes the level of acknowledgment requested from MongoDB for write operations. The level of the write concerns affects how quickly the write operation returns. 写入关注描述了MongoDB为写操作请求的确认级别。写入关注的级别会影响写操作返回的速度。When write operations have a weak write concern, they return quickly. With stronger write concerns, clients must wait after sending a write operation until MongoDB confirms the write operation at the requested write concern level. 当写操作具有弱写入关注时,它们会快速返回。对于更强的写入关注,客户端必须在发送写入操作后等待,直到MongoDB在请求的写入关注级别确认写入操作。With insufficient write concerns, write operations may appear to a client to have succeeded, but may not persist in some cases of server failure.由于写入关注不足,客户端可能会认为写入操作已成功,但在某些服务器故障的情况下可能不会持续。
See the Write Concern document for more information about choosing an appropriate write concern level for your deployment.有关为部署选择适当的写入关注级别的更多信息,请参阅写入关注文档。
Networking网络
Use Trusted Networking Environments使用受信任的网络环境
Always run MongoDB in a trusted environment, with network rules that prevent access from all unknown machines, systems, and networks. 始终在受信任的环境中运行MongoDB,网络规则防止来自所有未知机器、系统和网络的访问。As with any sensitive system that is dependent on network access, your MongoDB deployment should only be accessible to specific systems that require access, such as application servers, monitoring services, and other MongoDB components.与任何依赖于网络访问的敏感系一致性样,MongoDB部署应该只能访问需要访问的特定系统,如应用程序服务器、监控服务和其他MongoDB组件。
Important
By default, authorization is not enabled, and 默认情况下,未启用授权,mongod assumes a trusted environment. mongod假定环境可信。Enable 根据需要启用授权模式。authorization mode as needed. For more information on authentication mechanisms supported in MongoDB as well as authorization in MongoDB, see Authentication on Self-Managed Deployments and Role-Based Access Control in Self-Managed Deployments.有关MongoDB中支持的身份验证机制以及MongoDB中的授权的更多信息,请参阅自我管理部署中的身份验证和基于角色的访问控制。
For additional information and considerations on security, refer to the documents in the Security Section, specifically:有关安全的更多信息和注意事项,请参阅安全部分的文件,具体如下:
Security Checklist for Self-Managed Deployments自我管理部署的安全检查表Network and Configuration Hardening for Self-Managed Deployments自我管理部署的网络和配置强化
For Windows users, consider the Windows Server Technet Article on TCP Configuration when deploying MongoDB on Windows.对于Windows用户,在Windows上部署MongoDB时,请考虑Windows Server Technet上关于TCP配置的文章。
Disable HTTP Interface禁用HTTP接口
The HTTP interface is disabled by default. Do not enable the HTTP interface in production environments.默认情况下禁用HTTP接口。不要在生产环境中启用HTTP接口。
Manage Connection Pool Sizes管理连接池大小
Avoid overloading the connection resources of a 通过调整连接池大小以适应用例,避免使mongod or mongos instance by adjusting the connection pool size to suit your use case. mongod或mongos实例的连接资源过载。Start at 110-115% of the typical number of current database requests, and modify the connection pool size as needed. Refer to the Connection Pool Options for adjusting the connection pool size.从当前数据库请求典型数量的110-115%开始,根据需要修改连接池大小。有关调整连接池大小的信息,请参阅连接池选项。
The connPoolStats command returns information regarding the number of open connections to the current database for mongos and mongod instances in sharded clusters.connPoolStats命令返回有关分片集群中mongos和mongod实例与当前数据库的打开连接数的信息。
See also Allocate Sufficient RAM and CPU.另请参阅分配足够的RAM和CPU。
Adjust tcp_keepalive_time调整tcp_kealive_time
If the TCP keepalive value is greater than the TCP idle timeout on your cloud provider's load balancer, there is a risk that the system might silently drop connections. To reduce this risk, set 如果TCP keepalive值大于云提供商负载均衡器上的TCP空闲超时,则系统可能会静默断开连接。为了降低这种风险,请将tcp_keepalive_time to 120.tcp_kealive_time设置为120。
Note
To view the keepalive setting on Linux, use one of the following commands:要查看Linux上的keepalive设置,请使用以下命令之一:sysctl net.ipv4.tcp_keepalive_timeOr:或者:cat /proc/sys/net/ipv4/tcp_keepalive_timeThe value is measured in seconds.该值以秒为单位进行测量。Note
Although the setting name includes虽然设置名称包括ipv4, thetcp_keepalive_timevalue applies to both IPv4 and IPv6.ipv4,但tcp_kealive_time值适用于IPv4和IPv6。To change the要更改tcp_keepalive_timevalue, you can use one of the following commands, supplying a <value> in seconds:tcp_kealive_time值,可以使用以下命令之一,以秒为单位提供一个<value>:sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>Or:或者:echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_timeThese operations do not persist across system reboots. To persist the setting, add the following line to这些操作在系统重新启动后不会持续。要保持设置不变,请将以下行添加到/etc/sysctl.conf, supplying a <value> in seconds, and reboot the machine:/etc/sysctl.conf中,以秒为单位提供一个<value>,然后重新启动计算机:net.ipv4.tcp_keepalive_time = <value>Keepalive values greater than大于300seconds, (5 minutes) will be overridden onmongodandmongossockets and set to300seconds.300秒(5分钟)的Keepalive值将在mongod和mongos套接字上被覆盖,并设置为300秒。
To view the keepalive setting on Windows, issue the following command:要查看Windows上的保活设置,请发出以下命令:reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTimeThe registry value is not present by default. The system default, used if the value is absent, is默认情况下,注册表值不存在。如果该值不存在,则使用系统默认值7200000milliseconds or0x6ddd00in hexadecimal.7200000毫秒或十六进制0x6ddd00。To change the要更改KeepAliveTimevalue, use the following command in an Administrator Command Prompt, where<value>is expressed in hexadecimal (e.g.120000is0x1d4c0):KeepAliveTime值,请在管理员命令提示符中使用以下命令,其中<value>以十六进制表示(例如120000是0x1d4c0):reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>Windows users should consider the Windows Server Technet Article on KeepAliveTime for more information on setting keepalive for MongoDB deployments on Windows systems.Windows用户应该考虑Windows Server Technet上关于KeepAliveTime的文章,以获取有关在Windows系统上为MongoDB部署设置keepalive的更多信息。Keepalive values greater than or equal to 600000 milliseconds (10 minutes) will be ignored by大于或等于mongodandmongos.600000毫秒(10分钟)的Keepalive值将被mongod和mongos忽略。
Hardware Considerations硬件注意事项
MongoDB is designed specifically with commodity hardware in mind and has few hardware requirements or limitations. MongoDB's core components run on little-endian hardware, primarily x86/x86_64 processors. MongoDB是专门为商品硬件而设计的,几乎没有硬件要求或限制。MongoDB的核心组件运行在小端硬件上,主要是x86/x86_64处理器。Client libraries (i.e. drivers) can run on big or little endian systems.客户端库(即驱动程序)可以在大端序或小端序系统上运行。
Allocate Sufficient RAM and CPU分配足够的RAM和CPU
At a minimum, ensure that each 至少,确保每个mongod or mongos instance has access to two real cores or one multi-core physical CPU.mongod或mongos实例都可以访问两个真正的内核或一个多核物理CPU。
WiredTiger
The WiredTiger storage engine is multithreaded and can take advantage of additional CPU cores. Specifically, the total number of active threads (i.e. concurrent operations) relative to the number of available CPUs can impact performance:WiredTiger存储引擎是多线程的,可以利用额外的CPU内核。具体来说,活动线程(即并发操作)的总数相对于可用CPU的数量会影响性能:
Throughput increases as the number of concurrent active operations increases up to the number of CPUs.吞吐量随着并发活动操作的数量增加到CPU的数量而增加。Throughput decreases as the number of concurrent active operations exceeds the number of CPUs by some threshold amount.当并发活动操作的数量超过CPU数量的某个阈值时,吞吐量会降低。
The threshold depends on your application. You can determine the optimum number of concurrent active operations for your application by experimenting and measuring throughput. 阈值取决于应用程序。您可以通过实验和测量吞吐量来确定应用程序并发活动操作的最佳数量。The output from mongostat provides statistics on the number of active reads/writes in the (ar|aw) column.mongostat的输出提供了(ar|aw)列中活动读/写次数的统计数据。
With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.使用WiredTiger,MongoDB同时利用WiredTigeer内部缓存和文件系统缓存。
The default WiredTiger internal cache size is the larger of either:默认的WiredTiger内部缓存大小是以下两者中的较大值:
- 50% of (RAM - 1 GB), or
- 256 MB.
For example, on a system with a total of 4GB of RAM the WiredTiger cache uses 1.5GB of RAM (例如,在总共有4GB RAM的系统上,WiredTiger缓存使用1.5GB RAM(0.5 * (4 GB - 1 GB) = 1.5 GB). Conversely, on a system with a total of 1.25 GB of RAM WiredTiger allocates 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).0.5 * (4 GB - 1 GB) = 1.5 GB)。相反,在总共有1.25 GB RAM的系统上,WiredTiger将256 MB分配给WiredTigeer缓存,因为这超过了总RAM减去1 GB的一半(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB)。
Note
In some instances, such as when running in a container, the database can have memory constraints that are lower than the total system memory. In such instances, this memory limit, rather than the total system memory, is used as the maximum RAM available.在某些情况下,例如在容器中运行时,数据库的内存限制可能低于总系统内存。在这种情况下,这个内存限制,而不是整个系统内存,被用作可用的最大RAM。
To see the memory limit, see 要查看内存限制,请参阅hostInfo.system.memLimitMB.hostInfo.system.memLimitMB。
By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. Compression defaults are configurable at a global level and can also be set on a per-collection and per-index basis during collection and index creation.默认情况下,WiredTiger对所有集合使用Snappy块压缩,对所有索引使用前缀压缩。压缩默认值可以在全局级别进行配置,也可以在集合和索引创建期间根据每个集合和每个索引进行设置。
Different representations are used for data in the WiredTiger internal cache versus the on-disk format:与磁盘格式相比,WiredTiger内部缓存中的数据使用了不同的表示方式:
Data in the filesystem cache is the same as the on-disk format, including benefits of any compression for data files. The filesystem cache is used by the operating system to reduce disk I/O.文件系统缓存中的数据与磁盘上的格式相同,包括对数据文件进行任何压缩的好处。操作系统使用文件系统缓存来减少磁盘I/O。Indexes loaded in the WiredTiger internal cache have a different data representation to the on-disk format, but can still take advantage of index prefix compression to reduce RAM usage. Index prefix compression deduplicates common prefixes from indexed fields.加载在WiredTiger内部缓存中的索引具有与磁盘上格式不同的数据表示形式,但仍然可以利用索引前缀压缩来减少RAM使用。索引前缀压缩可消除索引字段中的常见前缀的重复。Collection data in the WiredTiger internal cache is uncompressed and uses a different representation from the on-disk format. Block compression can provide significant on-disk storage savings, but data must be uncompressed to be manipulated by the server.WiredTiger内部缓存中的集合数据是未压缩的,并使用与磁盘格式不同的表示形式。块压缩可以显著节省磁盘存储空间,但数据必须解压缩才能由服务器操作。
With the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.使用文件系统缓存,MongoDB会自动使用WiredTiger缓存或其他进程未使用的所有空闲内存。
To adjust the size of the WiredTiger internal cache, see 要调整WiredTiger内部缓存的大小,请参阅--wiredTigerCacheSizeGB and storage.wiredTiger.engineConfig.cacheSizeGB. --wiredTigerCacheSizeGB和storage.wiredTiger.engineConfig.cacheSizeGB。Avoid increasing the WiredTiger internal cache size above its default value. 避免将WiredTiger内部缓存大小增加到默认值以上。If your use case requires increased internal cache size, see 如果用例需要增加内部缓存大小,请参阅--wiredTigerCacheSizePct and storage.wiredTiger.engineConfig.cacheSizePct.--wiredTigerCacheSizePct和storage.wiredTiger.engineConfig.cacheSizePct。
Note
The storage.wiredTiger.engineConfig.cacheSizeGB limits the size of the WiredTiger internal cache. The operating system uses the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. storage.wiredTiger.engineConfig.cacheSizeGB限制了WiredTiger内部缓存的大小。操作系统使用可用的空闲内存进行文件系统缓存,这允许压缩的MongoDB数据文件留在内存中。In addition, the operating system uses any free RAM to buffer file system blocks and file system cache.此外,操作系统使用任何空闲RAM来缓冲文件系统块和文件系统缓存。
To accommodate the additional consumers of RAM, you may have to decrease WiredTiger internal cache size.为了容纳额外的RAM用户,您可能需要减小WiredTiger内部缓存大小。
The default WiredTiger internal cache size value assumes that there is a single 默认的WiredTiger内部缓存大小值假定每台机器只有一个mongod instance per machine. mongod实例。If a single machine contains multiple MongoDB instances, decrease the setting to accommodate the other 如果一台机器包含多个MongoDB实例,请减小设置以容纳其他mongod instances.mongod实例。
If you run 如果你在一个无法访问系统中所有可用RAM的容器(例如mongod in a container (for example, lxc, cgroups, Docker, etc.) that does not have access to all of the RAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB to a value less than the amount of RAM available in the container. lxc、cgroups、Docker等)中运行mongod,你必须将storage.wiredTiger.engineConfig.cacheSizeGB设置为小于容器中可用RAM量的值。The exact amount depends on the other processes running in the container. See 确切的数量取决于容器中运行的其他进程。请参阅memLimitMB.memLimitMB。
You can only provide one of either 您只能提供storage.wiredTiger.engineConfig.cacheSizeGB or storage.wiredTiger.engineConfig.cacheSizePct.storage.wiredTiger.engineConfig.cacheSizeGB或storage.wiredTiger.engineConfig.cacheSizePct中的一个。
To view statistics on the cache and eviction rate, see the 要查看缓存和驱逐率的统计信息,请参阅wiredTiger.cache field returned from the serverStatus command.serverStatus命令返回的wiredTiger.cache字段。
Compression and Encryption压缩和加密
When using encryption, CPUs equipped with AES-NI instruction-set extensions show significant performance advantages. If you are using MongoDB Enterprise with the Encrypted Storage Engine, choose a CPU that supports AES-NI for better performance.使用加密时,配备AES-NI指令集扩展的CPU显示出显著的性能优势。如果您使用的是带有加密存储引擎的MongoDB Enterprise,请选择支持AES-NI的CPU以获得更好的性能。
Tip
Use Solid State Disks (SSDs)使用固态硬盘(SSD)
MongoDB has good results and a good price-performance ratio with SATA SSD (Solid State Disk).MongoDB与SATA SSD(固态硬盘)具有良好的效果和良好的性价比。
Use SSD if available and economical.如果可用且经济,请使用SSD。
Commodity (SATA) spinning drives are often a good option, as the random I/O performance increase with more expensive spinning drives is not that dramatic (only on the order of 2x). Using SSDs or increasing RAM may be more effective in increasing I/O throughput.商品(SATA)旋转驱动器通常是一个不错的选择,因为使用更昂贵的旋转驱动器随机I/O性能的提高并没有那么显著(只有2倍左右)。使用SSD或增加RAM可能更有效地提高I/O吞吐量。
MongoDB and NUMA HardwareMongoDB和NUMA硬件
Running MongoDB on a system with Non-Uniform Memory Access (NUMA) can cause a number of operational problems, including slow performance for periods of time and high system process usage.在具有非一致性内存访问(NUMA)的系统上运行MongoDB可能会导致许多操作问题,包括一段时间内性能缓慢和系统进程使用率高。
When running MongoDB servers and clients on NUMA hardware, you should configure a memory interleave policy so that the host behaves in a non-NUMA fashion. MongoDB checks NUMA settings on start up when deployed on Linux (since version 2.0) and Windows (since version 2.6) machines. If the NUMA configuration may degrade performance, MongoDB prints a warning.在NUMA硬件上运行MongoDB服务器和客户端时,您应该配置内存交错策略,使主机以非NUMA方式运行。MongoDB在Linux(自2.0版本起)和Windows(自2.6版本起)机器上部署时,会在启动时检查NUMA设置。如果NUMA配置可能会降低性能,MongoDB会打印警告。
The numad daemon process can also reduce mongod performance. You should ensure numad is not enabled on MongoDB servers.numad守护进程也会降低mongod的性能。您应该确保MongoDB服务器上未启用numad。
Tip
The MySQL "swap insanity" problem and the effects of NUMA post, which describes the effects of NUMA on databases.MySQL的“交换疯狂”问题和NUMA post的影响,描述了NUMA对数据库的影响。The post introduces NUMA and its goals, and illustrates how these goals are not compatible with production databases.这篇文章介绍了NUMA及其目标,并说明了这些目标如何与生产数据库不兼容。Although the blog post addresses the impact of NUMA for MySQL, the issues for MongoDB are similar.尽管这篇博客文章讨论了NUMA对MySQL的影响,但MongoDB的问题是相似的。- NUMA: An Overview.
Configuring NUMA on Windows在Windows上配置NUMA
On Windows, memory interleaving must be enabled through the machine's BIOS. Consult your system documentation for details.在Windows上,必须通过机器的BIOS启用内存交错。有关详细信息,请参阅系统文档。
Configuring NUMA on Linux在Linux上配置NUMA
On Linux, you must disable zone reclaim and also ensure that your 在Linux上,您必须禁用区域回收,并确保mongod and mongos instances are started by numactl, which is generally configured through your platform's init system. You must perform both of these operations to properly disable NUMA for use with MongoDB.mongod和mongos实例由numactl启动,numactl通常通过您平台的init系统配置。您必须执行这两个操作才能正确禁用NUMA以与MongoDB一起使用。
Disable zone reclaim with one of the following commands:使用以下命令之一禁用区域回收:echo 0 | sudo tee /proc/sys/vm/zone_reclaim_modesudo sysctl -w vm.zone_reclaim_mode=0Ensure that确保mongodandmongosare started bynumactl.mongod和mongos由numactl启动。This is generally configured through your platform's init system. Run the following command to determine which init system is in use on your platform:这通常是通过平台的init系统配置的。运行以下命令以确定平台上正在使用哪个init系统:ps --no-headers -o comm 1If "如果是“systemd", your platform uses the systemd init system, and you must follow the steps in the systemd tab below to edit your MongoDB service file(s).systemd”,则平台使用systemd init系统,您必须按照下面systemd选项卡中的步骤编辑MongoDB服务文件。If "如果是“init", your platform uses the SysV Init system, and you do not need to perform this step. The default MongoDB init script for SysV Init includes the necessary steps to start MongoDB instances vianumactlby default.init”,则平台使用SysV init系统,您不需要执行此步骤。SysV init的默认MongoDB初始化脚本包括默认情况下通过numactl启动MongoDB实例的必要步骤。If you manage your own init scripts (i.e. you are not using either of these init systems), you must follow the steps in the Custom init scripts tab below to edit your custom init script(s).如果您管理自己的初始化脚本(即您没有使用这两个初始化系统中的任何一个),则必须按照下面“自定义初始化脚本”选项卡中的步骤编辑自定义初始化脚本。
Systemd
You must use您必须使用numactlto start each of yourmongodinstances, including all config servers,mongosinstances, and clients.numactl来启动每个mongod实例,包括所有配置服务器、mongos实例和客户端。Edit the default systemd service file for each as follows:按如下方式编辑每个的默认systemd服务文件:Copy the default MongoDB service file:复制默认的MongoDB服务文件:sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/Edit the编辑/etc/systemd/system/mongod.servicefile, and update theExecStartstatement to begin with:/etc/systemd/system/mongod.service文件,并更新ExecStart语句,使其以以下内容开头:/usr/bin/numactl --interleave=allExample示例If your existing如果您现有的ExecStartstatement reads:ExecStart语句为:ExecStart=/usr/bin/mongod --config /etc/mongod.confUpdate that statement to read:将该声明更新为:ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.confApply the change to将更改应用于systemd:systemd:sudo systemctl daemon-reloadRestart any running重新启动任何正在运行的mongodinstances:mongod实例:sudo systemctl stop mongod
sudo systemctl start mongodIf applicable, repeat these steps for any如果适用,对任何mongosinstances.mongos实例重复这些步骤。
Custom init scripts
You must use您必须使用numactlto start each of yourmongodinstances, including all config servers,mongosinstances, and clients.numactl来启动每个mongod实例,包括所有配置服务器、mongos实例和客户端。Install如果尚未安装,请为平台安装numactlfor your platform if not already installed. Refer to the documentation for your operating system for information on installing thenumactlpackage.numactl。有关安装numactl软件包的信息,请参阅操作系统的文档。Configure each of your custom init scripts to start each MongoDB instance via配置每个自定义init脚本,通过numactl:numactl启动每个MongoDB实例:numactl --interleave=all <path> <options>Where其中<path>is the path to the program you are starting and<options>are any optional arguments to pass to that program.<path>是您要启动的程序的路径,<options>是传递给该程序的任何可选参数。Example示例numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf
For more information, see the Documentation for /proc/sys/vm/*.有关更多信息,请参阅/proc/sys/vm/*的文档。
Disk and Storage Systems磁盘和存储系统
Swap
MongoDB performs best where swapping can be avoided or kept to a minimum, as retrieving data from swap will always be slower than accessing data in RAM. MongoDB在可以避免或尽量减少交换的情况下表现最佳,因为从交换中检索数据总是比访问RAM中的数据慢。However, if the system hosting MongoDB runs out of RAM, swapping can prevent the Linux OOM Killer from terminating the 但是,如果托管MongoDB的系统内存不足,交换可以防止Linux OOM杀手终止mongod process.mongod进程。
Generally, you should choose one of the following swap strategies:通常,您应该选择以下交换策略之一:
Assign swap space on your system, and configure the kernel to only permit swapping under high memory load, or在系统上分配交换空间,并将内核配置为仅允许在高内存负载下进行交换,或Do not assign swap space on your system, and configure the kernel to disable swapping entirely不要在系统上分配交换空间,并将内核配置为完全禁用交换
See Set vm.swappiness for instructions on configuring swap on your Linux system following these guidelines.有关按照这些准则在Linux系统上配置交换的说明,请参阅设置vm.swappiness。
Note
If your MongoDB instance is hosted on a system that also runs other software, such as a webserver, you should choose the first swap strategy. Do not disable swap in this case. 如果MongoDB实例托管在同时运行其他软件(如Web服务器)的系统上,则应选择第一种交换策略。在这种情况下,不要禁用交换。If possible, it is highly recommended that you run MongoDB on its own dedicated system.如果可能的话,强烈建议您在自己的专用系统上运行MongoDB。
RAID
For optimal performance in terms of the storage layer, use disks backed by RAID-10. RAID-5 and RAID-6 do not typically provide sufficient performance to support a MongoDB deployment.为了在存储层方面获得最佳性能,请使用RAID-10支持的磁盘。RAID-5和RAID-6通常不能提供足够的性能来支持MongoDB部署。
Remote Filesystems (NFS)远程文件系统(NFS)
With the WiredTiger storage engine, WiredTiger objects may be stored on remote file systems if the remote file system conforms to ISO/IEC 9945-1:1996 (POSIX.1). Because remote file systems are often slower than local file systems, using a remote file system for storage may degrade performance.使用WiredTiger存储引擎,如果远程文件系统符合ISO/IEC 9945-1:1996(POSIX.1),则WiredTigeer对象可以存储在远程文件系统上。由于远程文件系统通常比本地文件系统慢,因此使用远程文件系统进行存储可能会降低性能。
If you decide to use NFS, add the following NFS options to your 如果您决定使用NFS,请将以下NFS选项添加到/etc/fstab file:/etc/fstab文件中:
bghardnolocknoatimenointr
Depending on your kernel version, some of these values may already be set as the default. Consult your platform's documentation for more information.根据内核版本,其中一些值可能已经设置为默认值。有关更多信息,请参阅平台文档。
Separate Components onto Different Storage Devices将组件分离到不同的存储设备上
For improved performance, consider separating your database's data, journal, and logs onto different storage devices, based on your application's access and write pattern. Mount the components as separate filesystems and use symbolic links to map each component's path to the device storing it.为了提高性能,可以考虑根据应用程序的访问和写入模式,将数据库的数据、日志和日志分离到不同的存储设备上。将组件作为单独的文件系统挂载,并使用符号链接将每个组件的路径映射到存储它的设备。
For the WiredTiger storage engine, you can also store the indexes on a different storage device. See 对于WiredTiger存储引擎,您还可以将索引存储在其他存储设备上。请参阅storage.wiredTiger.engineConfig.directoryForIndexes.storage.wiredTiger.engineConfig.directoryForIndexes。
Note
Using different storage devices will affect your ability to create snapshot-style backups of your data, since the files will be on different devices and volumes.使用不同的存储设备会影响您创建数据快照式备份的能力,因为文件将位于不同的设备和卷上。
Scheduling日程安排
Scheduling for Virtual or Cloud Hosted Devices虚拟或云托管设备的调度
For local block devices attached to a virtual machine instance via the hypervisor or hosted by a cloud hosting provider, the guest operating system should use the cfq scheduler for best performance. 对于通过管理程序连接到虚拟机实例或由云托管提供商托管的本地块设备,客户操作系统应使用cfq调度程序以获得最佳性能。The cfq scheduler allows the operating system to defer I/O scheduling to the underlying hypervisor.cfq调度程序允许操作系统将I/O调度推迟到底层管理程序。
Note
The noop scheduler can be used for scheduling if all the following conditions are met:如果满足以下所有条件,则可以使用noop调度器进行调度:
The hypervisor is VMware.虚拟机监控程序是VMware。A replica set topology or sharded cluster is used.使用副本集拓扑或分片集群。The virtual machines are located on the same virtual host.虚拟机位于同一虚拟主机上。The underlying storage containing the DBpaths is a common LUN blockstore.包含DBpaths的底层存储是一个通用的LUN块存储。
Scheduling for Physical Servers物理服务器的调度
For physical servers, the operating system should use a deadline scheduler. The deadline scheduler caps maximum latency per request and maintains a good disk throughput that is best for disk-intensive database applications.对于物理服务器,操作系统应该使用截止日期调度程序。截止日期调度程序限制了每个请求的最大延迟,并保持了良好的磁盘吞吐量,最适合磁盘密集型数据库应用程序。
Architecture架构
Replica Sets副本集
See the Replica Set Architectures document for an overview of architectural considerations for replica set deployments.有关副本集部署的体系结构注意事项的概述,请参阅副本集架构文档。
Sharded Clusters分片集群
See Sharded Cluster Production Architecture for an overview of recommended sharded cluster architectures for production deployments.有关生产部署的推荐分片集群架构的概述,请参阅分片集群生产架构。
Compression压缩
WiredTiger can compress collection data using one of the following compression library:WiredTiger可以使用以下压缩库之一压缩集合数据:
-
- snappy
Provides a lower compression rate than提供的压缩率低于zliborzstdbut has a lower CPU cost than either.zlib或zstd,但CPU成本低于两者。
-
- zlib
Provides better compression rate than提供比snappybut has a higher CPU cost than bothsnappyandzstd.snappy更好的压缩率,但CPU成本高于snappy和zstd。
-
- zstd
Provides better compression rate than both提供比snappyandzliband has a lower CPU cost thanzlib.snappy和zlib更好的压缩率,并且比zlib的CPU成本更低。
By default, WiredTiger uses snappy compression library. 默认情况下,WiredTiger使用snappy压缩库。To change the compression setting, see 要更改压缩设置,请参阅storage.wiredTiger.collectionConfig.blockCompressor.storage.wiredTiger.collectionConfig.blockCompressor。
WiredTiger uses prefix compression on all indexes by default.默认情况下,WiredTiger对所有索引都使用前缀压缩。
Clock Synchronization时钟同步
MongoDB components keep logical clocks for supporting time-dependent operations. Using NTP to synchronize host machine clocks mitigates the risk of clock drift between components. MongoDB组件保持逻辑时钟以支持时间依赖的操作。使用NTP同步主机时钟可以降低组件之间的时钟漂移风险。Clock drift between components increases the likelihood of incorrect or abnormal behavior of time-dependent operations like the following:组件之间的时钟漂移增加了时间依赖操作的不正确或异常行为的可能性,如下所示:
If the underlying system clock of any given MongoDB component drifts a year or more from other components in the same deployment, communication between those members may become unreliable or halt altogether.如果任何给定MongoDB组件的底层系统时钟与同一部署中的其他组件漂移一年或更长时间,这些成员之间的通信可能会变得不可靠或完全停止。ThemaxAcceptableLogicalClockDriftSecsparameter controls the amount of acceptable clock drift between components. Clusters with a lower value ofmaxAcceptableLogicalClockDriftSecshave a correspondingly lower tolerance for clock drift.maxAcceptableLogicalClockDriftSecs参数控制组件之间可接受的时钟漂移量。maxAcceptableLogicalClockDriftSecs值较低的集群对时钟漂移的容忍度相应较低。Two cluster members with different system clocks may return different values for operations that return the current cluster or system time, such as具有不同系统时钟的两个集群成员可能会为返回当前集群或系统时间的操作返回不同的值,例如Date(),NOW, andCLUSTER_TIME.Date()、NOW和CLUSTER_TIME。Features which rely on timekeeping may have inconsistent or unpredictable behavior in clusters with clock drift between MongoDB components.依赖于计时的功能在MongoDB组件之间存在时钟漂移的集群中可能具有不一致或不可预测的行为。
Platform Specific Considerations平台特定考虑因素
MongoDB on Linux
Kernel and File Systems内核和文件系统
When running MongoDB in production on Linux, you should use Linux kernel version 2.6.36 or later, with either the XFS or EXT4 filesystem. If possible, use XFS as it generally performs better with MongoDB.在Linux上的生产环境中运行MongoDB时,您应该使用Linux内核版本2.6.36或更高版本,以及XFS或EXT4文件系统。如果可能的话,使用XFS,因为它通常在MongoDB中表现更好。
With the WiredTiger storage engine, using XFS is strongly recommended for data bearing nodes to avoid performance issues that may occur when using EXT4 with WiredTiger.对于WiredTiger存储引擎,强烈建议对数据承载节点使用XFS,以避免在将EXT4与WiredTiger一起使用时可能出现的性能问题。
In general, if you use the XFS file system, use at least version一般来说,如果您使用XFS文件系统,请至少使用Linux内核的2.6.25of the Linux Kernel.2.6.25版本。If you use the EXT4 file system, use at least version如果您使用EXT4文件系统,请至少使用Linux内核的2.6.28of the Linux Kernel.2.6.28版本。On Red Hat Enterprise Linux and CentOS, use at least version在Red Hat Enterprise Linux和CentOS上,至少使用Linux内核的2.6.18-194of the Linux kernel.2.6.18-194版本。
System C Library系统C库
MongoDB uses the GNU C Library (glibc) on Linux. Generally, each Linux distro provides its own vetted version of this library. MongoDB在Linux上使用GNU C库(glibc)。通常,每个Linux发行版都提供自己的经过审查的此库版本。For best results, use the latest update available for this system-provided version. You can check whether you have the latest version installed by using your system's package manager. For example:为了获得最佳效果,请使用此系统提供版本的最新更新。您可以使用系统的包管理器检查是否安装了最新版本。例如:
On RHEL / CentOS, the following command updates the system-provided GNU C Library:在RHEL/CentOS上,以下命令更新系统提供的GNU C库:sudo yum update glibcOn Ubuntu / Debian, the following command updates the system-provided GNU C Library:在Ubuntu/Debian上,以下命令更新系统提供的GNU C库:sudo apt-get install libc6
fsync() on Directories
Important
MongoDB requires a filesystem that supports MongoDB需要一个在目录上支持fsync() on directories. fsync()的文件系统。For example, HGFS and Virtual Box's shared folders do not support this operation.例如,HGFS和Virtual Box的共享文件夹不支持此操作。
Set vm.swappiness to 1 or 0
"Swappiness" is a Linux kernel setting that influences the behavior of the Virtual Memory manager.“Swappiness”是一个影响虚拟内存管理器行为的Linux内核设置。 The vm.swappiness setting ranges from 0 to 100: the higher the value, the more strongly it prefers swapping memory pages to disk over dropping pages from RAM.vm.swappiness设置的范围为0到100:值越高,它越喜欢将内存页面交换到磁盘,而不是从RAM中删除页面。
A setting of设置为0disables swapping entirely0将完全禁用交换[8].A setting of设置为1permits the kernel to swap only to avoid out-of-memory problems.1只允许内核交换以避免内存不足问题。A setting of设置为60tells the kernel to swap to disk often, and is the default value on many Linux distributions.60告诉内核经常交换到磁盘,这是许多Linux发行版的默认值。A setting of设置为100tells the kernel to swap aggressively to disk.100告诉内核积极地交换到磁盘。
MongoDB performs best where swapping can be avoided or kept to a minimum. As such you should set MongoDB在可以避免交换或将交换保持在最低限度的情况下表现最佳。因此,您应该根据应用程序需求和集群配置将vm.swappiness to either 1 or 0 depending on your application needs and cluster configuration.vm.swappiness设置为1或0。
Note
Most system and user processes run within a cgroup, which, by default, sets the 大多数系统和用户进程都在cgroup中运行,默认情况下,cgroup将vm.swappiness to 60. vm.swappiness设置为60。If you are running RHEL / CentOS, set 如果您运行的是RHEL/CentOS,请将vm.force_cgroup_v2_swappiness to 1 to ensure that the specified vm.swappiness value overrides any cgroup defaults.vm.force_cgroup_v2_swappiness设置为1,以确保指定的vm.swappiness值覆盖任何cgroup默认值。
| [8] | 3.5, or RHEL / CentOS kernel versions previous to 2.6.32-303, a vm.swappiness setting of 0 would still allow the kernel to swap in certain emergency situations.3.5之前的Linux内核版本或2.6.32-303之前的RHEL/CentOS内核版本,vm.swappiness设置为0仍将允许内核在某些紧急情况下进行交换。 |
Note
If your MongoDB instance is hosted on a system that also runs other software, such as a webserver, you should set 如果MongoDB实例托管在同时运行其他软件(如Web服务器)的系统上,则应将vm.swappiness to 1. If possible, it is highly recommended that you run MongoDB on its own dedicated system.vm.swappiness设置为1。如果可能的话,强烈建议您在自己的专用系统上运行MongoDB。
To check the current swappiness setting on your system, run:要检查系统上的当前swappiness设置,请运行:cat /proc/sys/vm/swappinessTo change swappiness on your system:要更改系统上的swappity,请执行以下操作:Edit the编辑/etc/sysctl.conffile and add the following line:/etc/sysctl.conf文件并添加以下行:vm.swappiness = 1Run the following command to apply the setting:运行以下命令以应用设置:sudo sysctl -p
Note
If you are running RHEL / CentOS and using a 如果您运行的是RHEL/CentOS并使用优化的性能配置文件,您还必须编辑所选的配置文件,将tuned performance profile, you must also edit your chosen profile to set vm.swappiness to 1 or 0.vm.swappiness设置为1或0。
Recommended Configuration推荐配置
For all MongoDB deployments:对于所有MongoDB部署:
Use the Network Time Protocol (NTP) to synchronize time among your hosts. This is especially important in sharded clusters.使用网络时间协议(NTP)在主机之间同步时间。这在分片集群中尤为重要。
For the WiredTiger storage engines, consider the following recommendations:对于WiredTiger存储引擎,请考虑以下建议:
Turn off关闭包含数据库文件的存储卷的atimefor the storage volume containing the database files.atime。Adjust the根据ulimitsettings for your platform according to the recommendations in the ulimit reference.ulimit参考中的建议调整平台的ulimit设置。Low低ulimitvalues will negatively affect MongoDB when under heavy use and can lead to failed connections to MongoDB processes and loss of service.ulimit值在频繁使用时会对MongoDB产生负面影响,并可能导致与MongoDB进程的连接失败和服务丢失。Note
If the如果打开文件数的ulimitvalue for number of open files is under64000, MongoDB generates a startup warning.ulimit值低于64000,MongoDB会生成启动警告。If you are running MongoDB 8.0, enable Transparent Hugepages.如果您运行的是MongoDB 8.0,请启用透明护圈。If you are running MongoDB 7.0 or earlier, disable Transparent Hugepages. In earlier versions, MongoDB performs better with typical (4096 bytes) virtual memory pages.如果您运行的是MongoDB 7.0或更早版本,请禁用透明护圈。在早期版本中,MongoDB在典型的(4096字节)虚拟内存页面上表现更好。
Disable NUMA in your BIOS. If that is not possible, see MongoDB on NUMA Hardware.在BIOS中禁用NUMA。如果这不可能,请参阅NUMA硬件上的MongoDB。Configure SELinux for MongoDB if you are not using the default MongoDB directory paths or ports.如果您没有使用默认的MongoDB目录路径或端口,请为MongoDB配置SELinux。Note
If you are using SELinux, any MongoDB operation that requires server-side JavaScript will result in segfault errors.如果你使用的是SELinux,任何需要服务器端JavaScript的MongoDB操作都会导致segfault错误。Disable Server-Side Execution of JavaScript禁用服务器端执行JavaScriptdescribes how to disable execution of server-side JavaScript.描述了如何禁用服务器端JavaScript的执行。
For the WiredTiger storage engine:对于WiredTiger存储引擎:
Set the readahead setting between 8 and 32 regardless of storage media type (spinning disk, SSD, etc.).将预读设置设置在8到32之间,而不管存储介质类型(旋转磁盘、SSD等)如何。Higher readahead commonly benefits sequential I/O operations. Since MongoDB disk access patterns are generally random, using higher readahead settings provides limited benefit or potential performance degradation.较高的预读通常有利于顺序I/O操作。由于MongoDB磁盘访问模式通常是随机的,因此使用更高的预读设置只能带来有限的好处或潜在的性能下降。As such, for optimal MongoDB performance, set readahead between 8 and 32, unless testing shows a measurable, repeatable, and reliable benefit in a higher readahead value.因此,为了获得最佳的MongoDB性能,请将预读设置在8到32之间,除非测试显示在更高的预读值中有可衡量、可重复和可靠的好处。MongoDBcommercial support商业支持can provide advice and guidance on alternate readahead configurations.可以就替代预读配置提供建议和指导。
MongoDB and TLS/SSL Libraries以及TLS/SSL库
On Linux platforms, you may observe one of the following statements in the MongoDB log:在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)
These warnings indicate that the system's TLS/SSL libraries are different from the TLS/SSL libraries that the 这些警告表明,系统的TLS/SSL库与mongod was compiled against. mongod编译时使用的TLS/SSL库不同。Typically these messages do not require intervention; however, you can use the following operations to determine the symbol versions that 通常,这些消息不需要干预;但是,您可以使用以下操作来确定mongod expects:mongod期望的符号版本:
objdump -T <path to mongod>/mongod | grep " SSL_"
objdump -T <path to mongod>/mongod | grep " CRYPTO_"
These operations will return output that resembles one the of the following lines:这些操作将返回类似于以下行之一的输出:
0000000000000000 DF *UND* 0000000000000000 libssl.so.10 SSL_write
0000000000000000 DF *UND* 0000000000000000 OPENSSL_1.0.0 SSL_write
The last two strings in this output are the symbol version and symbol name. Compare these values with the values returned by the following operations to detect symbol version mismatches:此输出中的最后两个字符串是符号版本和符号名称。将这些值与以下操作返回的值进行比较,以检测符号版本不匹配:
objdump -T <path to TLS/SSL libs>/libssl.so.1*
objdump -T <path to TLS/SSL libs>/libcrypto.so.1*
This procedure is neither exact nor exhaustive: many symbols used by 这个过程既不精确也不详尽:mongod from the libcrypto library do not begin with CRYPTO_.mongod在libcrypto库中使用的许多符号都不是以CRYPTO_开头的。
MongoDB on Windows
For MongoDB instances using the WiredTiger storage engine, performance on Windows is comparable to performance on Linux.对于使用WiredTiger存储引擎的MongoDB实例,Windows上的性能与Linux上的性能相当。
MongoDB on Virtual Environments虚拟环境中的MongoDB
This section describes considerations when running MongoDB in some of the more common virtual environments.本节介绍在一些更常见的虚拟环境中运行MongoDB时的注意事项。
For all platforms, consider Scheduling.对于所有平台,请考虑调度。
AWS EC2
There are two performance configurations to consider:有两种性能配置需要考虑:
Reproducible performance for performance testing or benchmarking, and用于性能测试或基准测试的可再现性能,以及Raw maximum performance原始最大性能
To tune performance on EC2 for either configuration, you should:要调整EC2上任一配置的性能,您应该:
Enable AWS Enhanced Networking for your instance. Not all instance types support Enhanced Networking.为实例启用AWS增强网络。并非所有实例类型都支持增强网络。To learn more about Enhanced Networking, see to the AWS documentation.要了解有关增强网络的更多信息,请参阅AWS文档。Set将tcp_keepalive_timeto 120.tcp_kealive_time设置为120。
If you are concerned more about reproducible performance on EC2, you should also:如果您更关心EC2上的可重复性能,您还应该:
Use provisioned IOPS for the storage, with separate devices for journal and data. Do not use the ephemeral (SSD) storage available on most instance types as their performance changes moment to moment. (The为存储使用配置的IOPS,日志和数据使用单独的设备。不要使用大多数实例类型上可用的临时(SSD)存储,因为它们的性能会随时发生变化。(iseries is a notable exception, but very expensive.)i系列是一个明显的例外,但非常昂贵。)Disable DVFS and CPU power saving modes.禁用DVFS和CPU省电模式。Disable hyperthreading.禁用超线程。Use使用numactlto bind memory locality to a single socket.numactl将内存位置绑定到单个套接字。
Azure
Use Premium Storage. Microsoft Azure offers two general types of storage: Standard storage, and Premium storage. MongoDB on Azure has better performance when using Premium storage than it does with Standard storage.使用高级存储。Microsoft Azure提供两种通用类型的存储:标准存储和高级存储。Azure上的MongoDB在使用高级存储时比使用标准存储时具有更好的性能。
VMware
MongoDB is compatible with VMware.MongoDB与VMware兼容。
VMware supports memory overcommitment, where you can assign more memory to your virtual machines than the physical machine has available. When memory is overcommitted, the hypervisor reallocates memory between the virtual machines. VMware支持内存超量使用,您可以为虚拟机分配比物理机可用的更多内存。当内存超量使用时,管理程序会在虚拟机之间重新分配内存。VMware's balloon driver (VMware的气球驱动程序(vmmemctl) reclaims the pages that are considered least valuable.vmmemctl)回收被认为价值最低的页面。
The balloon driver resides inside the guest operating system. Under certain configurations, when the balloon driver expands, it can interfere with MongoDB's memory management and affect MongoDB's performance.气球驱动程序位于客户操作系统内部。在某些配置下,当气球驱动程序扩展时,它可能会干扰MongoDB的内存管理并影响MongoDB的性能。
To prevent negative performance impact from the balloon driver and memory overcommitment features, reserve the full amount of memory for the virtual machine running MongoDB. Reserving the appropriate amount of memory for the virtual machine prevents the balloon from inflating in the local operating system when there is memory pressure in the hypervisor.为了防止气球驱动程序和内存超量使用功能对性能产生负面影响,请为运行MongoDB的虚拟机保留全部内存。为虚拟机保留适量的内存可以防止在管理程序内存压力时气球在本地操作系统中膨胀。
Even though the balloon driver and memory overcommitment features can negatively affect MongoDB performance under certain configurations, do not disable these features. If you disable these features, the hypervisor may use its swap space to fulfill memory requests, which negatively affects performance.即使气球驱动程序和内存超量使用功能在某些配置下会对MongoDB的性能产生负面影响,也不要禁用这些功能。如果禁用这些功能,管理程序可能会使用其交换空间来满足内存请求,这会对性能产生负面影响。
Ensure that virtual machines stay on a specific ESX/ESXi host by setting VMware's affinity rules. 通过设置VMware的关联规则,确保虚拟机保持在特定的ESX/ESXi主机上。If you must manually migrate a virtual machine to another host and the 如果必须手动将虚拟机迁移到另一台主机,并且虚拟机上的mongod instance on the virtual machine is the primary, you must first step down the primary and then shut down the instance.mongod实例是primary实例,则必须首先关闭主实例,然后关闭实例。
Follow the networking best practices for vMotion and VMKernel. 遵循vMotion和VMKernel的网络最佳实践。Failure to follow the best practices can result in performance problems and affect replica set and sharded cluster high availability mechanisms.不遵循最佳实践可能会导致性能问题,并影响副本集和分片集群的高可用性机制。
You can clone a virtual machine running MongoDB. You might use this function to deploy a new virtual host to add as a member of a replica set.您可以克隆运行MongoDB的虚拟机。您可以使用此功能部署新的虚拟主机,以添加为副本集的成员。
KVM
MongoDB is compatible with KVM.MongoDB与KVM兼容。
KVM supports memory overcommitment, where you can assign more memory to your virtual machines than the physical machine has available. When memory is overcommitted, the hypervisor reallocates memory between the virtual machines. KVM's balloon driver reclaims the pages that are considered least valuable.KVM支持内存超量使用,您可以为虚拟机分配比物理机可用的更多内存。当内存超量使用时,管理程序会在虚拟机之间重新分配内存。KVM的气球驱动程序回收被认为最没有价值的页面。
The balloon driver resides inside the guest operating system. Under certain configurations, when the balloon driver expands, it can interfere with MongoDB's memory management and affect MongoDB's performance.气球驱动程序位于客户操作系统内部。在某些配置下,当气球驱动程序扩展时,它可能会干扰MongoDB的内存管理并影响MongoDB的性能。
To prevent negative performance impact from the balloon driver and memory overcommitment features, reserve the full amount of memory for the virtual machine running MongoDB. Reserving the appropriate amount of memory for the virtual machine prevents the balloon from inflating in the local operating system when there is memory pressure in the hypervisor.为了防止气球驱动程序和内存超量使用功能对性能产生负面影响,请为运行MongoDB的虚拟机保留全部内存。为虚拟机保留适量的内存可以防止在管理程序内存压力时气球在本地操作系统中膨胀。
Even though the balloon driver and memory overcommitment features can negatively affect MongoDB performance under certain configurations, do not disable these features. If you disable these features, the hypervisor may use its swap space to fulfill memory requests, which negatively affects performance.即使气球驱动程序和内存超量使用功能在某些配置下会对MongoDB的性能产生负面影响,也不要禁用这些功能。如果禁用这些功能,管理程序可能会使用其交换空间来满足内存请求,这会对性能产生负面影响。
Performance Monitoring性能监控
iostat
On Linux, use the 在Linux上,使用iostat command to check if disk I/O is a bottleneck for your database. Specify a number of seconds when running iostat to avoid displaying stats covering the time since server boot.iostat命令检查磁盘I/O是否是数据库的瓶颈。指定运行iostat时的秒数,以避免显示自服务器启动以来的时间统计数据。
For example, the following command will display extended statistics and the time for each displayed report, with traffic in MB/s, at one second intervals:例如,以下命令将以1秒的间隔显示每个显示的报告的扩展统计信息和时间,流量单位为MB/s:
iostat -xmt 1
Key fields from iostat:iostat的键段:
%util: this is the most useful field for a quick check, it indicates what percent of the time the device/drive is in use.:这是快速检查最有用的字段,它表示设备/驱动器正在使用的时间百分比。avgrq-sz: average request size. Smaller number for this value reflect more random IO operations.:平均请求大小。此值的较小数字反映了更多的随机IO操作。
bwm-ng
bwm-ng is a command-line tool for monitoring network use. If you suspect a network-based bottleneck, you may use 是一个用于监控网络使用情况的命令行工具。如果您怀疑存在基于网络的瓶颈,可以使用bwm-ng开始诊断过程。bwm-ng to begin your diagnostic process.
Backups备份
To make backups of your MongoDB database, please refer to MongoDB Backup Methods Overview.要备份MongoDB数据库,请参阅MongoDB备份方法概述。