在本页面
本文档提供了常见诊断问题的解答。
如果找不到所需的答案,请查看常见问题解答的完整列表或将问题发布到 MongoDB社区。
mongod
意外停止运行的进程的信息?¶如果mongod
在UNIX或基于UNIX的平台上意外关闭,并且mongod
无法记录关闭或错误消息,请检查系统日志中与MongoDB有关的消息。例如,对于位于中的日志/var/log/messages
,请使用以下命令:
keepalive
时间会影响MongoDB部署吗?¶如果在客户端和服务器之间或分片群集或副本集的成员之间的通信中遇到网络超时或套接字错误,请检查受影响系统的TCP keepalive值。
7200
默认情况下,许多操作系统将此值设置为秒(两个小时)。对于MongoDB,通常在120
几秒钟(两分钟)的时间内使用较短的keepalive值可获得更好的结果。
如果您的MongoDB部署遇到与Keepalive相关的问题,则必须更改所有受影响系统上的Keepalive价值。这包括所有正在运行的计算机mongod
或mongos
进程,以及托管连接到MongoDB的客户端进程的所有计算机。
要在Linux上查看keepalive设置,请使用以下命令之一:
要么:
该值以秒为单位。
注意
尽管设置名称包括ipv4
,但该
tcp_keepalive_time
值同时适用于IPv4和IPv6。
要更改该tcp_keepalive_time
值,可以使用以下命令之一,以秒为单位提供一个<value>:
要在Windows上查看keepalive设置,请发出以下命令:
注册表值默认情况下不存在。如果不存在该值,则使用系统默认值,以7200000
毫秒为单位或
0x6ddd00
以十六进制表示。
要改变KeepAliveTime
值,在管理员使用以下命令命令提示符,其中<value>
以十六进制(例如,表示120000
为0x1d4c0
):
Windows用户应查看关于KeepAliveTime的Windows Server Technet文章,以获取有关在Windows系统上为MongoDB部署设置keepalive的更多信息。和会忽略大于或等于600000毫秒(10分钟)的
keepalive值
。mongod
mongos
如果您在MongoDB日志中看到大量的连接和重新连接消息,则说明客户端经常连接和断开与MongoDB服务器的连接。对于不使用请求池的应用程序(例如CGI),这是正常的行为。考虑使用FastCGI,Apache模块或其他某种持久性应用程序服务器来减少连接开销。
从版本4.0开始,MongoDB 为独立和副本集提供免费的云监视。免费监控可提供有关您的部署的信息,包括:
有关更多信息,请参见免费监控。
在MongoDB的云管理和 操作管理员,在MongoDB的企业提供先进的内部部署解决方案包括监测功能,其运行的MongoDB部署收集数据,并提供基于数据可视化和警报。
有关更多信息,另请参阅MongoDB Cloud Manager文档和 Ops Manager文档。
完整的第三方工具列表可作为 Monitoring for MongoDB文档的一部分。
没有。
如果缓存没有足够的空间来加载其他数据,则WiredTiger会将页面从缓存中逐出以释放空间。
注意
该storage.wiredTiger.engineConfig.cacheSizeGB
限制WiredTiger内部高速缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存,从而允许压缩的MongoDB数据文件保留在内存中。此外,操作系统将使用任何可用的RAM来缓冲文件系统块和文件系统缓存。
为了容纳更多的RAM使用者,您可能必须减小WiredTiger内部缓存的大小。
默认的WiredTiger内部缓存大小值假定mongod
每台计算机有一个实例。如果一台机器包含多个MongoDB实例,则应减小设置以容纳其他mongod
实例。
如果你运行mongod
在一个容器(例如lxc
,
cgroups
,Docker,等等),它没有访问所有系统中可用的RAM,你必须设置storage.wiredTiger.engineConfig.cacheSizeGB
的值小于RAM容器使用的量。确切的数量取决于容器中运行的其他进程。请参阅
memLimitMB
。
要查看有关缓存和逐出的统计信息,请使用
serverStatus
命令。该
wiredTiger.cache
字段保存有关缓存和逐出的信息。
有关某些关键缓存和逐出统计信息(例如和)的说明,请参见。wiredTiger.cache.bytes currently in the
cache
wiredTiger.cache.tracked dirty bytes
in the cache
wiredTiger.cache
要调整WiredTiger内部缓存的大小,请参阅
storage.wiredTiger.engineConfig.cacheSizeGB
和
--wiredTigerCacheSizeGB
。避免将WiredTiger内部缓存的大小增加到其默认值以上。
通过WiredTiger,MongoDB可以利用WiredTiger内部缓存和文件系统缓存。
从MongoDB 3.4开始,默认的WiredTiger内部缓存大小是以下两者中的较大者:
例如,在总共有4GB RAM的系统上,WiredTiger缓存将使用1.5GB RAM()。相反,总内存为1.25 GB的系统将为WiredTiger缓存分配256 MB,因为这是总RAM的一半以上减去1 GB()。0.5 * (4 GB - 1 GB) = 1.5 GB
0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB
注意
在某些情况下,例如在容器中运行时,数据库的内存限制可能低于系统总内存。在这种情况下,此内存限制而不是系统总内存将用作最大可用RAM。
要查看内存限制,请参阅hostInfo.system.memLimitMB
。
默认情况下,WiredTiger对所有集合使用Snappy块压缩,对所有索引使用前缀压缩。压缩默认值是可以在全局级别配置的,也可以在收集和索引创建期间基于每个集合和每个索引进行设置。
WiredTiger内部缓存中的数据与磁盘格式使用不同的表示形式:
通过文件系统缓存,MongoDB自动使用WiredTiger缓存或其他进程未使用的所有可用内存。
要调整WiredTiger内部缓存的大小,请参阅
storage.wiredTiger.engineConfig.cacheSizeGB
和
--wiredTigerCacheSizeGB
。避免将WiredTiger内部缓存的大小增加到其默认值以上。
注意
该storage.wiredTiger.engineConfig.cacheSizeGB
限制WiredTiger内部高速缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存,从而允许压缩的MongoDB数据文件保留在内存中。此外,操作系统将使用任何可用的RAM来缓冲文件系统块和文件系统缓存。
为了容纳更多的RAM使用者,您可能必须减小WiredTiger内部缓存的大小。
默认的WiredTiger内部缓存大小值假定mongod
每台计算机有一个实例。如果一台机器包含多个MongoDB实例,则应减小设置以容纳其他mongod
实例。
如果你运行mongod
在一个容器(例如lxc
,
cgroups
,Docker,等等),它没有访问所有系统中可用的RAM,你必须设置storage.wiredTiger.engineConfig.cacheSizeGB
的值小于RAM容器使用的量。确切的数量取决于容器中运行的其他进程。请参阅
memLimitMB
。
要查看有关高速缓存和逐出速率的统计信息,请参阅命令wiredTiger.cache
返回的
字段serverStatus
。
维持成功的分片群集的两个最重要的因素是:
通过确保为部署选择最佳的分片密钥,并确保始终在当前资源饱和之前为集群添加额外的容量,就可以防止分片遇到的大多数问题。继续阅读您在生产环境中可能遇到的特定问题。
您的集群必须具有足够的数据才能进行分片。分片的工作原理是在分片之间迁移块,直到每个分片具有大致相同数量的块。
默认的块大小是64 MB。直到集群中的块不平衡超过迁移阈值, MongoDB才会开始迁移 。此行为有助于防止不必要的块迁移,因为这可能会降低整个群集的性能。
如果您刚刚部署了分片群集,请确保有足够的数据使分片有效。如果没有足够的数据来创建八个以上的64 MB块,则所有数据将保留在一个分片上。降低块大小设置,或向集群添加更多数据。
作为一个相关问题,系统将仅在插入或更新时拆分块,这意味着,如果配置分片并且不继续执行插入和更新操作,则数据库将不会创建任何块。您可以等待,直到应用程序手动插入数据或 拆分块。
最后,如果分片密钥的基数较低,则MongoDB可能无法在数据之间创建足够的拆分。
在某些情况下,单个分片或集群的子集将收到不成比例的流量和工作负载部分。在几乎所有情况下,这都是分片密钥导致的,该分片密钥无法有效地允许写入缩放。
您也可能有“热块”。在这种情况下,您可以通过拆分然后迁移这些块的一部分来解决问题。
如果您刚刚部署了分片群集,则可能需要考虑针对新群集的故障排除建议,该群集中的数据保留在单个分片上。
如果群集最初是平衡的,但后来又出现了数据分布不均的情况,请考虑以下可能的原因: