On this page本页内容
This page details system configurations that affect MongoDB, especially when running in production.本页详细介绍了影响MongoDB的系统配置,尤其是在生产环境中运行时。
MongoDB 4.2 removes the deprecated MMAPv1 storage engine. MongoDB 4.2删除了不推荐使用的MMAPv1存储引擎。To change your MMAPv1 storage engine deployment to WiredTiger Storage Engine, see:要将MMAPv1存储引擎部署更改为WiredTiger存储引擎,请参阅:
MongoDB Atlas is a cloud-hosted database-as-a-service. 是一个云托管的数据库即服务。MongoDB Cloud Manager, a hosted service, and 是一种托管服务,而Ops Manager, an on-premise solution, provide monitoring, backup, and automation of MongoDB instances. 是一个本地解决方案,提供MongoDB实例的监控、备份和自动化。For documentation, see Atlas documentation, the MongoDB Cloud Manager documentation and Ops Manager documentation有关文档,请参阅Atlas文档、MongoDB Cloud Manager文档和Ops Manager文档
For running in production, refer to the Recommended Platforms for operating system recommendations.有关在生产环境中运行的信息,请参阅操作系统建议的推荐平台。
MongoDB requires the following minimum MongoDB至少需要以下x86_64
microarchitectures:x86_64
微体系结构:
[2]
For Intel 对于Intel x86_64
, MongoDB requires one of:x86_64
,MongoDB需要以下选项之一:
For AMD 对于AMD x86_64
, MongoDB requires:x86_64
,MongoDB需要:
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
平台。
RHEL / CentOS 6 | |
Ubuntu 16.04 | |
macOS 10.13 |
Amazon Linux 2 | ✓ | ✓ | ✓ | ✓ |
---|---|---|---|---|
Amazon Linux 2013.03 and later | ✓ | ✓ | ||
Debian 10 | ✓ | ✓ | 4.2.1+ | |
Debian 9 | ✓ | ✓ | ✓ | ✓ |
RHEL/CentOS/Oracle Linux [1] 8.0 and later | ✓ | ✓ | 4.2.1+ | 4.0.14+ |
RHEL/CentOS/Oracle Linux [1] 7.0 and later | ✓ | ✓ | ✓ | ✓ |
RHEL/CentOS/Oracle Linux [1] 6.2 and later | ✓ | ✓ | ✓ | |
SLES 15 | ✓ | ✓ | 4.2.1+ | |
SLES 12 | ✓ | ✓ | ✓ | ✓ |
Ubuntu 20.04 | ✓ | ✓ | ||
Ubuntu 18.04 | ✓ | ✓ | ✓ | 4.0.1+ |
Ubuntu 16.04 | ✓ | ✓ | ✓ | |
Windows Server 2019 | ✓ | ✓ | ✓ | |
Windows 10 / Server 2016 | ✓ | ✓ | ✓ | ✓ |
Windows 8.1 / Server 2012 R2 | ✓ | ✓ | ||
Windows 8 / Server 2012 | ✓ | ✓ | ||
Windows 7 / Server 2008 R2 | ✓ | ✓ | ||
macOS 10.14 and later | ✓ | ✓ | ✓ | ✓ |
macOS 10.13 | ✓ | ✓ | ✓ | |
macOS 10.12 | ✓ | ✓ |
[1] | (1, 2, 3) |
[2] | |
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
平台。
Ubuntu 16.04 |
Platform | ||||
---|---|---|---|---|
Amazon Linux 2 | ✓ | 4.4.4+ | 4.2.13+ | |
RHEL/CentOS 8 | ✓ | 4.4.4+ | ||
Ubuntu 20.04 | ✓ | ✓ | ||
Ubuntu 18.04 | ✓ | ✓ | ✓ | |
Ubuntu 16.04 | Enterprise only | Enterprise only | ✓ |
RHEL/CentOS 7 PPC64LE | |
Ubuntu 18.04 PPC64LE |
Platform | 5.0 Enterprise | 4.4 Enterprise | 4.2 Enterprise | 4.0 Enterprise |
---|---|---|---|---|
RHEL/CentOS 8 | ✓ | ✓ | 4.2.7+ | |
RHEL/CentOS 7 | ✓ | ✓ | ✓ | |
Ubuntu 18.04 | ✓ | ✓ |
SLES 12 s390x | |
Ubuntu 18.04 s390x |
Platform | 5.0 Community | 4.4 Community | 4.2 Community | 4.0 Community |
---|---|---|---|---|
RHEL/CentOS 7 | ✓ | ✓ | 4.2.0 - 4.2.9 | 4.0.6 - 4.0.13 |
RHEL/CentOS 6 | 4.0.0 - 4.0.13 | |||
SLES 12 | 4.4.0 - 4.4.6 | 4.2.0 - 4.2.9 | 4.0.6 - 4.0.13 | |
Ubuntu 18.04 | 4.4.0 - 4.4.6 | 4.2.1 - 4.2.9 | 4.0.6 - 4.0.13 |
SLES 12 s390x | |
Ubuntu 18.04 s390x |
Platform | 5.0 Enterprise | 4.4 Enterprise | 4.2 Enterprise | 4.0 Enterprise |
---|---|---|---|---|
RHEL/CentOS 7 | ✓ | ✓ | ✓ | 4.0.6+ |
RHEL/CentOS 6 | 4.2.4+ | ✓ | ||
SLES 12 | 4.4.0 - 4.4.6 | 4.2.0 - 4.2.14 | 4.0.6 - 4.0.24 | |
Ubuntu 18.04 | 4.4.0 - 4.4.6 | 4.2.1 - 4.2.14 | 4.0.6 - 4.0.25 |
RHEL 7 UBI on Docker | |
Ubuntu 16.04 on Docker |
Platform | 5.0 Community & Enterprise | |
---|---|---|
RHEL UBI 8 on Docker 19.03+ | ✓ | |
RHEL UBI 7 on Docker 19.03+ | ✓ | |
Ubuntu 18.04 on Docker 19.03+ | ✓ | |
Ubuntu 16.04 on Docker 19.03+ | ✓ |
While MongoDB supports a variety of platforms, the following operating systems are recommended for production use on 虽然MongoDB支持多种平台,但建议在x86_64
architecture:x86_64
体系结构上生产使用以下操作系统:
Be sure you have the latest stable release.确保您拥有最新的稳定版本。
All MongoDB releases are available on the MongoDB Download Center page. MongoDB下载中心页面上提供了所有MongoDB版本。The MongoDB Download Center is a good place to verify the current stable release, even if you are installing via a package manager.MongoDB下载中心是验证当前稳定版本的好地方,即使您是通过包管理器安装的。
For other MongoDB products, refer either to the MongoDB Download Center page or 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
.mongod
必须拥有指定dbPath
的读写权限。
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.客户端可以在写入操作进行时读取文档,多个线程可以同时修改集合中的不同文档。
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内核以及如何提高操作吞吐量的信息。
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
因崩溃或其他严重故障而终止的情况下,快速恢复写入日志但未写入数据文件的写入操作。
Leave journaling enabled in order to ensure that 启用日志记录,以确保mongod
will be able to recover its data files and keep the data files in a valid state following a crash. mongod
能够恢复其数据文件,并在崩溃后将数据文件保持在有效状态。See Journaling for more information.有关详细信息,请参阅日志。
Starting in MongoDB 4.0, you cannot specify 从MongoDB 4.0开始,不能为使用WiredTiger存储引擎的副本集成员指定--nojournal
option or storage.journal.enabled: false
for replica set members that use the WiredTiger storage engine.--nojournal
选项或storage.journal.enabled: false
。
Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.从MongoDB 3.6开始,如果写入请求确认,您可以使用因果一致的会话来读取自己的写入。
Prior to MongoDB 3.6, in order to read your own writes you must issue your write operation with 在MongoDB 3.6之前,为了读取您自己的写操作,您必须使用{ w: "majority" }
write concern, and then issue your read operation with primary
read preference, and either "majority"
or "linearizable"
read concern.{ w: "majority" }
写关注点发出写操作,然后使用primary
读偏好以及"majority"
或"linearizable"
读关注点发出读操作。
Write concern describes the level of acknowledgement requested from MongoDB for write operations. 写入关注点描述了MongoDB为写操作请求的确认级别。The level of the write concerns affects how quickly the write operation returns. 写入关注点的级别影响写入操作返回的速度。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.有关为部署选择适当的写关注点级别的更多信息,请参阅写入关注点文档。
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组件。
By default, authorization is not enabled, and 默认情况下,未启用授权,mongod
assumes a trusted environment. mongod
假定一个受信任的环境。Enable 根据需要启用authorization
mode as needed. authorization
模式。For more information on authentication mechanisms supported in MongoDB as well as authorization in MongoDB, see Authentication and Role-Based Access Control.有关MongoDB支持的身份验证机制以及MongoDB中的授权的更多信息,请参阅身份验证和基于角色的访问控制。
For additional information and considerations on security, refer to the documents in the Security Section, specifically:有关安全的更多信息和注意事项,请参阅安全章节中的文件,特别是:
For Windows users, consider the Windows Server Technet Article on TCP Configuration when deploying MongoDB on Windows.对于Windows用户,在Windows上部署MongoDB时,请参阅有关TCP配置的Windows Server Technet文章。
Changed in version 3.6.在版本3.6中更改。
Earlier versions of MongoDB provide an HTTP interface to check the status of the server and, optionally, run queries. 早期版本的MongoDB提供了一个HTTP接口来检查服务器的状态,并可以选择运行查询。The HTTP interface is disabled by default. 默认情况下,HTTP接口被禁用。Do not enable the HTTP interface in production environments.不要在生产环境中启用HTTP接口。
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. 从当前数据库请求典型数量的110-115%开始,并根据需要修改连接池大小。Refer to the Connection Pool Options for adjusting the connection pool size.请参阅连接池选项以调整连接池大小。
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。
MongoDB is designed specifically with commodity hardware in mind and has few hardware requirements or limitations. MongoDB是专门针对商品硬件设计的,几乎没有硬件要求或限制。MongoDB's core components run on little-endian hardware, primarily x86/x86_64 processors. Client libraries (i.e. drivers) can run on big or little endian systems.MongoDB的核心组件运行在小端硬件上,主要是x86/x86_64处理器。客户端库(即驱动程序)可以在大或小端系统上运行。
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。
The WiredTiger storage engine is multithreaded and can take advantage of additional CPU cores. WiredTiger存储引擎是多线程的,可以利用额外的CPU内核。Specifically, the total number of active threads (i.e. concurrent operations) relative to the number of available CPUs can impact performance:具体而言,活动线程(即并发操作)的总数相对于可用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同时利用WiredTig内部缓存和文件系统缓存。
Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:从MongoDB 3.4开始,默认的WiredTiger内部缓存大小为以下值中的较大值:
For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (例如,在总共有4GB RAM的系统上,WiredTiger缓存将使用1.5GB的RAM(0.5 * (4 GB - 1 GB) = 1.5 GB
). 0.5 * (4 GB - 1 GB) = 1.5 GB
)。Conversely, a system with a total of 1.25 GB of RAM will allocate 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (相反,总RAM为1.25 GB的系统将为WiredTiger缓存分配256 MB,因为这超过了总RAM减去1 GB的一半(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
).0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
)。
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. 默认情况下,WiredTiger对所有集合使用Snappy块压缩,对所有索引使用前缀压缩。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.压缩默认值可以在全局级别进行配置,也可以在集合和索引创建期间根据每个集合和每个索引进行设置。
Different representations are used for data in the WiredTiger internal cache versus the on-disk format:WiredTiger内部缓存中的数据与磁盘上的数据格式使用不同的表示:
Via 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内部缓存的大小,请参阅storage.wiredTiger.engineConfig.cacheSizeGB
and --wiredTigerCacheSizeGB
. storage.wiredTiger.engineConfig.cacheSizeGB
和--wiredTigerCacheSizeGB
。Avoid increasing the WiredTiger internal cache size above its default value.避免将WiredTiger内部缓存大小增加到其默认值以上。
The 存储storage.wiredTiger.engineConfig.cacheSizeGB
limits the size of the WiredTiger internal cache. storage.wiredTiger.engineConfig.cacheSizeGB
限制了WiredTiger内部缓存的大小。The operating system will use the available free memory for filesystem cache, which allows the compressed MongoDB data files to stay in memory. 操作系统将使用可用的空闲内存进行文件系统缓存,这允许压缩的MongoDB数据文件留在内存中。In addition, the operating system will use 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, then you should decrease the setting to accommodate the other 如果一台机器包含多个MongoDB实例,那么应该减少设置以适应其他mongod
instances.mongod
实例。
If you run 如果在无法访问系统中所有可用RAM的容器(例如mongod
in a container (e.g. 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
。
To view statistics on the cache and eviction rate, see the 要查看缓存和收回率的统计信息,请参阅wiredTiger.cache
field returned from the serverStatus
command.serverStatus
命令返回的wiredTiger.cache
字段。
When using encryption, CPUs equipped with AES-NI instruction-set extensions show significant performance advantages. 使用加密时,配备AES-NI指令集扩展的CPU显示出显著的性能优势。If you are using MongoDB Enterprise with the Encrypted Storage Engine, choose a CPU that supports AES-NI for better performance.如果将MongoDB Enterprise与加密存储引擎一起使用,请选择支持AES-NI的CPU以获得更好的性能。
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). 商品(SATA)旋转驱动器通常是一个不错的选择,因为更昂贵的旋转驱动器的随机I/O性能提高并不是那么显著(仅为2倍)。Using SSDs or increasing RAM may be more effective in increasing I/O throughput.使用SSD或增加RAM可能更有效地增加I/O吞吐量。
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. 在NUMA硬件上运行MongoDB服务器和客户端时,应配置内存交错策略,以便主机以非NUMA方式运行。MongoDB checks NUMA settings on start up when deployed on Linux (since version 2.0) and Windows (since version 2.6) machines. MongoDB在Linux(2.0版以后)和Windows(2.6版以后)机器上部署时,在启动时检查NUMA设置。If the NUMA configuration may degrade performance, MongoDB prints a warning.如果NUMA配置可能会降低性能,MongoDB会打印警告。
On Windows, memory interleaving must be enabled through the machine's BIOS. 在Windows上,必须通过计算机的BIOS启用内存交错。Consult your system documentation for details.有关详细信息,请参阅系统文档。
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. mongod
和mongos
实例由numactl启动,通常通过平台的init系统进行配置。You must perform both of these operations to properly disable NUMA for use with MongoDB.您必须执行这两个操作才能正确禁用NUMA以用于MongoDB。
Disable zone reclaim with one of the following commands:使用以下命令之一禁用区域回收:
echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode
sudo sysctl -w vm.zone_reclaim_mode=0
Ensure that 确保mongod
and mongos
are started by numactl
. 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 1
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服务文件。init
", your platform uses the SysV Init system, and you do not need to perform this step. init
”,您的平台将使用SysV init系统,您不需要执行此步骤。numactl
by default.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).如果您管理自己的init脚本(即,您没有使用这些init系统中的任何一个),则必须按照下面“自定义init脚本”选项卡中的步骤来编辑自定义初始化脚本。
You must use 必须使用numactl
to start each of your mongod
instances, including all config servers, mongos
instances, 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.service
file, and update the ExecStart
statement to begin with:/etc/systemd/system/mongod.service
文件,并更新ExecStart
语句以开始:
/usr/bin/numactl --interleave=all
If your existing 如果现有的ExecStart
statement reads:ExecStart
语句为:
ExecStart=/usr/bin/mongod --config /etc/mongod.conf
Update that statement to read:将该语句更新为:
ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf
Apply the change to 将更改应用于systemd
:systemd
:
sudo systemctl daemon-reload
Restart any running 重新启动所有正在运行的mongod
instances:mongod
实例:
sudo systemctl stop mongod sudo systemctl start mongod
If applicable, repeat these steps for any 如果适用,对任何mongos
instances.mongos
实例重复这些步骤。
You must use 必须使用numactl
to start each of your mongod
instances, including all config servers, mongos
instances, and clients.numactl
启动每个mongod
实例,包括所有配置服务器、mongos
实例和客户端。
Install 如果尚未安装,请为您的平台安装numactl
for your platform if not already installed. numactl
。Refer to the documentation for your operating system for information on installing the 有关安装numactl
package.numactl
包的信息,请参阅操作系统的文档。
Configure each of your custom init scripts to start each MongoDB instance via 配置每个自定义初始化脚本,通过numactl启动每个MongoDB实例:numactl
:
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>
是传递给该程序的任何可选参数。
numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf
For more information, see the Documentation for /proc/sys/vm/*.有关详细信息,请参阅/proc/sys/vm/*的文档。
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 Killer终止mongod
process.mongod
进程。
Generally, you should choose one of the following swap strategies:通常,您应该选择以下掉期策略之一:
See Set vm.swappiness for instructions on configuring swap on your Linux system following these guidelines.请参阅Set vm.swapiness,了解有关按照这些指导原则在Linux系统上配置swap的说明。
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. 如果您的MongoDB实例托管在同时运行其他软件的系统上,例如Web服务器,则应选择第一个交换策略。Do not disable swap in this case. 在这种情况下不要禁用交换。If possible, it is highly recommended that you run MongoDB on its own dedicated system.如果可能,强烈建议您在自己的专用系统上运行MongoDB。
For optimal performance in terms of the storage layer, use disks backed by RAID-10. 为了在存储层方面获得最佳性能,请使用RAID-10支持的磁盘。RAID-5 and RAID-6 do not typically provide sufficient performance to support a MongoDB deployment.RAID-5和RAID-6通常不能提供足够的性能来支持MongoDB部署。
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). 使用WiredTiger存储引擎,如果远程文件系统符合ISO/IEC 9945-1:1996(POSIX.1),则WiredTig对象可以存储在远程文件系统上。Because remote file systems are often slower than local file systems, using a remote file system for storage may degrade performance.由于远程文件系统通常比本地文件系统慢,因此使用远程文件系统进行存储可能会降低性能。
If you decide to use NFS, add the following NFS options to your 如果决定使用NFS,请将以下NFS选项添加到/etc/fstab
file:/etc/fstab
文件中:
bg
hard
nolock
noatime
nointr
Depending on your kernel version, some of these values may already be set as the default. 根据您的内核版本,其中一些值可能已经设置为默认值。Consult your platform's documentation for more information.有关详细信息,请参阅您平台的文档。
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. 对于WiredTiger存储引擎,您还可以将索引存储在不同的存储设备上。See 请参阅storage.wiredTiger.engineConfig.directoryForIndexes
.storage.wiredTiger.engineConfig.directoryForIndexes
。
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.使用不同的存储设备将影响您创建数据快照式备份的能力,因为这些文件将位于不同的设备和卷上。
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 a noop scheduler for best performance. 对于通过虚拟机监控程序连接到虚拟机实例或由云托管提供商托管的本地块设备,来宾操作系统应使用noop调度程序以获得最佳性能。The noop scheduler allows the operating system to defer I/O scheduling to the underlying hypervisor.noop调度程序允许操作系统将I/O调度推迟到底层虚拟机监控程序。
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.截止日期调度程序限制每个请求的最大延迟,并保持良好的磁盘吞吐量,这最适合磁盘密集型数据库应用程序。
See the Replica Set Architectures document for an overview of architectural considerations for replica set deployments.有关副本集部署的体系结构注意事项的概述,请参阅副本集体系结构文档。
See Sharded Cluster Production Architecture for an overview of recommended sharded cluster architectures for production deployments.请参阅分片群集生产架构,以了解建议用于生产部署的分片群集架构的概述。
WiredTiger can compress collection data using one of the following compression library:WiredTiger可以使用以下压缩库之一压缩集合数据:
zlib
or zstd
but has a lower CPU cost than either.zlib
或zstd
更低的压缩率,但CPU成本低于两者。snappy
but has a higher CPU cost than both snappy
and zstd
.snapy
更好的压缩率,但比snaply
和zstd具有更高的CPU成本。snappy
and zlib
and has a lower CPU cost than zlib
.snapy
和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对所有索引使用前缀压缩。
MongoDB components keep logical clocks for supporting time-dependent operations. MongoDB组件保持逻辑时钟,以支持与时间相关的操作。Using NTP to synchronize host machine clocks mitigates the risk of clock drift between components. 使用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组件的底层系统时钟与同一部署中的其他组件相差一年或更长时间,则这些成员之间的通信可能变得不可靠或完全停止。
The maxAcceptableLogicalClockDriftSecs
parameter controls the amount of acceptable clock drift between components. maxAcceptableLogicalClockDriftSecs
参数控制组件之间可接受的时钟漂移量。Clusters with a lower value of maxAcceptableLogicalClockDriftSecs
have a correspondingly lower tolerance for clock drift.maxAcceptableLogicalClockDriftSecs
值较低的集群对时钟漂移的容忍度相对较低。
Date()
, NOW
, and CLUSTER_TIME
.Date()
、NOW
和CLUSTER_TIME
。NTP synchronization is required for deployments running MongoDB lower than 对于使用Wired Tiger存储引擎运行低于3.4.6
or 3.2.17
with the Wired Tiger storage engine, where clock drift could lead to checkpoint hangs. 3.4.6
或3.2.17
的MongoDB的部署,需要NTP同步,因为时钟漂移可能导致检查点挂起。The issue was fixed in MongoDB 3.4.6+ and MongoDB 3.2.17+, and is resolved in all point release of MongoDB 3.6, 4.0, 4.2, and later releases.该问题已在MongoDB 3.4.6+和MongoDB 3.2.17+中修复,并在MongoDB3.6、4.0、4.2及更高版本的所有点版本中得到解决。
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. 在Linux上的生产环境中运行MongoDB时,应使用Linux内核版本2.6.36或更高版本,以及XFS或EXT4文件系统。If possible, use XFS as it generally performs better with MongoDB.如果可能,请使用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.25
of the Linux Kernel.2.6.25
版本。
2.6.28
of the Linux Kernel.2.6.28
版本。2.6.18-194
of the Linux kernel.2.6.18-194
版本的Linux内核。MongoDB uses the GNU C Library(glibc) on Linux. MongoDB在Linux上使用GNU C库(glibc)。Generally, each Linux distro provides its own vetted version of this library. 通常,每个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 glibc
On Ubuntu / Debian, the following command updates the system-provided GNU C Library:在Ubuntu/Debian上,以下命令更新系统提供的GNU C库:
sudo apt-get install libc6
fsync()
on Directoriesfsync()
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的共享文件夹不支持此操作。
vm.swappiness
to 1
or 0
vm.swapiness
设置为1
或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.swapiness
设置的范围从0
到100
:该值越高,它越倾向于将内存页面交换到磁盘,而不是从RAM中删除页面。
0
disables swapping entirely0
将完全禁用交换 [3].1
permits the kernel to swap only to avoid out-of-memory problems.1
只允许内核交换以避免内存不足问题。60
tells the kernel to swap to disk often, and is the default value on many Linux distributions.60
告诉内核经常交换到磁盘,这是许多Linux发行版的默认值。100
tells the kernel to swap aggressively to disk.100
会告诉内核积极地交换到磁盘。MongoDB performs best where swapping can be avoided or kept to a minimum. MongoDB在可以避免交换或将交换保持在最低限度的地方表现最佳。As such you should set 因此,您应该根据应用程序需求和集群配置将vm.swappiness
to either 1
or 0
depending on your application needs and cluster configuration.vm.swapiness
设置为1
或0
。
[3] | 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.swapiness 设置为0 仍然允许内核在某些紧急情况下进行交换。 |
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
. vm.swapiness
设置为1
。If possible, it is highly recommended that you run MongoDB on its own dedicated system.如果可能,强烈建议您在自己的专用系统上运行MongoDB。
To check the current swappiness setting on your system, run:要检查系统上的当前交换设置,请运行:
cat /proc/sys/vm/swappiness
To change swappiness on your system:要更改系统上的交换:
Edit the 编辑/etc/sysctl.conf
file and add the following line:/etc/sysctl.conf
文件并添加以下行:
vm.swappiness = 1
Run the following command to apply the setting:运行以下命令以应用设置:
sudo sysctl -p
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.swapiness
设置为1
或0
。
For all MongoDB deployments:对于所有MongoDB部署:
For the WiredTiger storage engines, consider the following recommendations:对于WiredTiger存储引擎,请考虑以下建议:
atime
for the storage volume containing the database files.atime
。Adjust the 根据ulimit
settings for your platform according to the recommendations in the ulimit reference. ulimit
参考中的建议调整平台的ulimit设置。Low 低ulimit
values will negatively affect MongoDB when under heavy use and can lead to failed connections to MongoDB processes and loss of service.ulimit
值将在大量使用时对MongoDB产生负面影响,并可能导致与MongoDB进程的连接失败和服务丢失。
Starting in MongoDB 4.4, a startup error is generated if the 从MongoDB 4.4开始,如果打开文件数的ulimit
value for number of open files is under 64000
.ulimit
值低于64000,则会生成启动错误。
Configure SELinux for MongoDB if you are not using the default MongoDB directory paths or ports.如果未使用默认MongoDB目录路径或端口,请为MongoDB配置SELinux。
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 describes how to disable execution of server-side JavaScript.禁用服务器端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.).无论存储介质类型(旋转磁盘、SSD等)如何,都将预读设置设置在8和32之间。
Higher readahead commonly benefits sequential I/O operations. 较高的预读通常有利于顺序I/O操作。Since MongoDB disk access patterns are generally random, using higher readahead settings provides limited benefit or potential performance degradation. 由于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性能,请将readahead设置在8到32之间,除非测试显示较高的readahea值具有可测量、可重复和可靠的优点。MongoDB commercial support can provide advice and guidance on alternate readahead configurations.可以提供关于备用预读配置的建议和指导。
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_
开头的。
For MongoDB instances using the WiredTiger storage engine, performance on Windows is comparable to performance on Linux.对于使用WiredTiger存储引擎的MongoDB实例,Windows上的性能与Linux上的性能相当。
This section describes considerations when running MongoDB in some of the more common virtual environments.本节介绍在一些更常见的虚拟环境中运行MongoDB时的注意事项。
For all platforms, consider Scheduling.对于所有平台,请考虑调度。
There are two performance configurations to consider:有两种性能配置需要考虑:
To tune performance on EC2 for either configuration, you should:要为两种配置调优EC2上的性能,您应该:
Enable AWS Enhanced Networking for your instance. 为您的实例启用AWS增强型网络。Not all instance types support Enhanced Networking.并非所有实例类型都支持增强型网络。
To learn more about Enhanced Networking, see to the AWS documentation.要了解有关增强型网络的更多信息,请参阅AWS文档。
If you are concerned more about reproducible performance on EC2, you should also:如果您更关心EC2的可复制性能,您还应:
i
series is a notable exception, but very expensive.)i
系列是一个显著的例外,但非常昂贵。)Disable DVFS and CPU power saving modes.禁用DVFS和CPU节能模式。
Disable hyperthreading.禁用超读。
numactl
to bind memory locality to a single socket.numactl
将内存位置绑定到单个套接字。Use Premium Storage. 使用高级存储。Microsoft Azure offers two general types of storage: Standard storage, and Premium storage. Microsoft Azure提供两种一般类型的存储:标准存储和高级存储。MongoDB on Azure has better performance when using Premium storage than it does with Standard storage.Azure上的MongoDB在使用高级存储时比使用标准存储时具有更好的性能。
The TCP idle timeout on the Azure load balancer is 240 seconds by default, which can cause it to silently drop connections if the TCP keepalive on your Azure systems is greater than this value. 默认情况下,Azure负载平衡器上的TCP空闲超时为240秒,如果您的Azure系统上的TCP保持活动状态大于此值,这可能会导致它静默地断开连接。You should set 您应该将tcp_keepalive_time
to 120 to ameliorate this problem.tcp_keepalive_time
设置为120以改善此问题。
To view the keepalive setting on Linux, use one of the following commands:要查看Linux上的keepalive设置,请使用以下命令之一:
sysctl net.ipv4.tcp_keepalive_time
Or:或者:
cat /proc/sys/net/ipv4/tcp_keepalive_time
The value is measured in seconds.该值以秒为单位测量。
Although the setting name includes 尽管设置名称包括ipv4
, the tcp_keepalive_time
value applies to both IPv4 and IPv6.ipv4
,但tcp_keepalive_time
值同时适用于ipv4和IPv6。
To change the 要更改tcp_keepalive_time
value, you can use one of the following commands, supplying a <value> in seconds:tcp_keepalive_time
值,可以使用以下命令之一,以秒为单位提供<value>
:
sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>
Or:或者:
echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time
These 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 大于300
seconds, (5 minutes) will be overridden on mongod
and mongos
sockets and set to 300
seconds.300
秒(5分钟)的Keepalive值将在mongod
和mongos
套接字上被覆盖,并设置为300
秒。
To view the keepalive setting on Windows, issue the following command:要在Windows上查看keepalive设置,请发出以下命令:
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime
The registry value is not present by default. 默认情况下,注册表值不存在。The system default, used if the value is absent, is 如果该值不存在,则使用系统默认值为7200000
milliseconds or 0x6ddd00
in hexadecimal.7200000
毫秒或0x6ddd00
(十六进制)。
To change the 要更改KeepAliveTime
value, use the following command in an Administrator Command Prompt, where <value>
is expressed in hexadecimal (e.g. 120000
is 0x1d4c0
):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用户应考虑有关KeepAliveTime的Windows Server Technet文章,以了解有关在Windows系统上为MongoDB部署设置keepalive的更多信息。Keepalive values greater than or equal to 600000 milliseconds (10 minutes) will be ignored by 大于或等于600000毫秒(10分钟)的Keepalive值将被mongod
and mongos
.mongod
和mongos
忽略。
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. VMware支持内存超量使用,您可以为虚拟机分配比物理机可用内存更多的内存。When memory is overcommitted, the hypervisor reallocates memory between the virtual machines. 当内存超量使用时,虚拟机监控程序会在虚拟机之间重新分配内存。VMware's balloon driver (VMware的气球驱动程序(vmmemctl)回收被认为最不值钱的页面。vmmemctl
) reclaims the pages that are considered least valuable.
The balloon driver resides inside the guest operating system. 气球驱动程序驻留在来宾操作系统中。When the balloon driver expands, it may induce the guest operating system to reclaim memory from guest applications, which can interfere with MongoDB's memory management and affect MongoDB's performance.当气球驱动程序扩展时,它可能会导致来宾操作系统从来宾应用程序中回收内存,这会干扰MongoDB的内存管理并影响MongoDB性能。
Do not disable the balloon driver and memory overcommitment features. 不要禁用气球驱动程序和内存超限功能。This can cause the hypervisor to use its swap which will affect performance. 这可能导致虚拟机监控程序使用其交换,从而影响性能。Instead, map and reserve the full amount of memory for the virtual machine running MongoDB. 相反,映射并保留运行MongoDB的虚拟机的全部内存。This ensures that the balloon will not be inflated in the local operating system if there is memory pressure in the hypervisor due to an overcommitted configuration.这可以确保,如果由于过度提交配置而导致虚拟机监控程序内存压力,则气球不会在本地操作系统中膨胀。
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,则必须首先关闭primary,然后关闭该实例。
Follow the networking best practices for vMotion and the VMKernel. 遵循vMotion和VMKernel的网络最佳实践。Failure to follow the best practices can result in performance problems and affect replica set and sharded cluster high availability mechanisms.不遵循最佳实践可能会导致性能问题,并影响副本集和分片群集的高可用性机制。
It is possible to clone a virtual machine running MongoDB. 可以克隆运行MongoDB的虚拟机。You might use this function to spin up a new virtual host to add as a member of a replica set. 您可以使用此功能启动一个新的虚拟主机,将其添加为副本集的成员。If you clone a VM with journaling enabled, the clone snapshot will be valid. 如果克隆启用日志记录的VM,克隆快照将有效。If not using journaling, first stop 如果不使用日志记录,首先停止mongod
, then clone the VM, and finally, restart mongod
.mongod
,然后克隆VM,最后重新启动mongod
。
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. KVM支持内存超限,您可以为虚拟机分配比物理机可用内存更多的内存。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的气球驱动程序会回收被认为最没有价值的页面。
The balloon driver resides inside the guest operating system. When the balloon driver expands, it may induce the guest operating system to reclaim memory from guest applications, which can interfere with MongoDB's memory management and affect MongoDB's performance.气球驱动程序驻留在来宾操作系统中。当气球驱动程序扩展时,它可能会导致来宾操作系统从来宾应用程序中回收内存,这会干扰MongoDB的内存管理并影响MongoDB性能。
Do not disable the balloon driver and memory overcommitment features. 不要禁用气球驱动程序和内存超限功能。This can cause the hypervisor to use its swap which will affect performance. 这可能导致虚拟机监控程序使用其交换,从而影响性能。Instead, map and reserve the full amount of memory for the virtual machine running MongoDB. 相反,映射并保留运行MongoDB的虚拟机的全部内存。This ensures that the balloon will not be inflated in the local operating system if there is memory pressure in the hypervisor due to an overcommitted configuration.这可以确保,如果由于过度提交配置而导致虚拟机监控程序内存压力,则气球不会在本地操作系统中膨胀。
Starting in version 4.0, MongoDB offers free Cloud monitoring for standalones and replica sets. 从版本4.0开始,MongoDB为标准和副本集提供免费云监控。For more information, see Free Monitoring.有关详细信息,请参阅免费监控。
On Linux, use the 在Linux上,使用iostat
command to check if disk I/O is a bottleneck for your database. iostat
命令检查磁盘I/O是否是数据库的瓶颈。Specify a number of seconds when running iostat to avoid displaying stats covering the time since server boot.运行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
:
%util
avgrq-sz
bwm-ng is a command-line tool for monitoring network use. 是用于监视网络使用的命令行工具。If you suspect a network-based bottleneck, you may use 如果您怀疑存在基于网络的瓶颈,可以使用bwm-ng
to begin your diagnostic process.bwm-ng
开始诊断过程。
To make backups of your MongoDB database, please refer to MongoDB Backup Methods Overview.要备份MongoDB数据库,请参阅MongoDB备份方法概述。