FAQ: MongoDB诊断

在本页面

本文档提供了常见诊断问题的答案。

如果找不到所需的答案,请查看常见问题解答完整列表或将问题发布到 MongoDB社区

在哪里可以找到有关mongod进程意外停止运行的信息?

如果mongod在UNIX或基于UNIX的平台上意外关闭,并且mongod无法记录关闭或错误消息,请检查系统日志中与MongoDB有关的消息。例如,使用以下命令查看位于/var/log/messages中的日志:

复制

sudo grep mongod /var/log/messages
sudo grep score /var/log/messages

TCP keepalive时间会影响MongoDB部署吗?

(译者注:tcp keepalive时间设置,主要用来探测连接对端是否还存活。当你建立一个TCP连接的时候,便有一组定时器与之绑定在一起。其中的一些定时器就用于处理keepalive过程。当keepalive定时器到0的时候,我们便会给对端发送一个不包含数据部分的keepalive探测包。如果我们收到了keepalive探测包的回复消息,那么我们就可以断定连接依然是OK的。如果我们没有收到对端keepalive探测包的回复消息,我们便可以断定连接已经不可用,进而可以采取一些措施。)

在客户端和服务器之间或者分片集群或副本集的成员之间,如果通信中遇到网络超时或套接字错误,请检查受影响系统的TCP keepalive值

许多操作系统默认将TCP keepalive值设置为7200秒(两个小时)。对于MongoDB,通常情况下,保持较短时间值(120几秒钟(两分钟)),您将获得更好的结果。

如果您的MongoDB部署遇到与keepalive相关的问题,则必须更改所有受影响系统上的keepalive价值。这些系统包括所有正在运行mongodmongos 的计算机以及连接到MongoDB的客户端进程的所有计算机。

调整TCP keepalive值:

  • Linux

  • Windows

  • macOS

  • 要在Linux上查看keepalive设置,请使用以下命令之一:

    复制

    sysctl net.ipv4.tcp_keepalive_time

    Or:

复制

cat /proc/sys/net/ipv4/tcp_keepalive_time

该值以秒为单位测量。

注意

尽管设置名称包括ipv4,但该 tcp_keepalive_time值同时适用于IPv4和IPv6。

  • 要更改该tcp_keepalive_time值,可以使用以下命令之一,以秒为单位提供一个:

复制

sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>

或者:

复制

echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time

这些操作不会在系统重新启动后持续存在。要保留设置,请将以下行添加到中/etc/sysctl.conf,在几秒钟内提供一个,然后重新启动计算机:

复制

net.ipv4.tcp_keepalive_time = <value>

mongodmongos进程将设置Keepalive值为300秒(5分钟),来重写覆盖大于5分钟的设置。

  • 要在Windows上查看keepalive设置,请使用以下命令之一:

复制

reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime

注册表值默认情况下不存在。如果没有该值,则使用系统默认值,以7200000毫秒为单位或 0x6ddd00以十六进制表示。

  • 要改变KeepAliveTime值,在管理员使用以下命令提示符,其中以十六进制(例如,表示1200000x1d4c0):

复制

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>

Windows用户应该查看KeepAliveTime上Windows Server Technet章节,以获取有关在Windows系统上为MongoDB部署设置keepalive的更多信息。mongodmongos会忽略大于或等于600000毫秒(10分钟)的 keepalive值 。

  • 要在macOS上查看keepalive设置,请使用以下命令之一:

复制

sysctl net.inet.tcp.keepidle

该值以秒为单位测量。

  • 要更改该net.inet.tcp.keepidle值,可以使用以下命令,以毫秒为单位提供一个 :

复制

sudo sysctl net.inet.tcp.keepidle=<value>

此操作不会在系统重新启动后持续存在,必须在每次系统重新启动时进行设置。请参阅操作系统的文档,以获取有关持久设置此值的说明。mongodmongos 会忽略大于或等于600000毫秒(10分钟)的keepalive值。

注意

在macOS 10.15 Catalina中,Apple不再允许配置该net.inet.tcp.keepidle选项。

您将需要重新启动mongodmongos 进程,新的Keepalive系统设置才能生效。

为什么MongoDB记录这么多“Connection Accepted” 事件?

如果您在MongoDB日志中看到大量的连接和重新连接消息,则说明客户端与MongoDB服务器经常连接和断开。对于不使用请求池的应用程序(例如CGI),这是正常的行为。考虑使用FastCGI,Apache模块或其他某种持久性应用程序服务器来减少连接开销。

如果这些连接不影响性能,则可以使用运行时quiet选项或命令行选项 --quiet从日志中禁止显示这些消息。

哪些工具可用于监视MongoDB?

从版本4.0开始,MongoDB 为单机部署和副本集提供免费的云监控。免费监控可提供如下部署的信息:

  • 操作执行时间

  • 内存使用情况

  • CPU使用率

  • 操作计数

有关更多信息,请参见免费监控

MongoDB Cloud Manager在MongoDB的企业提供先进的内部部署解决方案的Ops Manager包括监控功能,其收集运行的MongoDB部署数据,并提供基于数据的可视化和警报。

有关更多信息,另请参阅MongoDB Cloud Manager文档Ops Manager文档

Monitoring for MongoDB文档中提供了完整的第三方工具列表。

WiredTiger存储引擎的内存诊断

我的working set必须适合内存吗?

不需要。

如果缓存没有足够的空间来加载其他数据,则WiredTiger会将页面从缓存中逐出以释放空间。

注意

storage.wiredTiger.engineConfig.cacheSizeGB限制WiredTiger内部缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存,从而允许压缩的MongoDB数据文件保留在内存中。此外,操作系统将使用任何可用的RAM来缓冲文件系统块和文件系统缓存。

为了容纳更多的内存使用者,您可能必须减小WiredTiger内部缓存的大小。

默认的WiredTiger内部缓存大小值假定每台计算机有一个mongod实例。如果一台机器包含多个MongoDB实例,则您应减小设置以容纳其他mongod 实例。

如果你在一个容器(例如lxccgroups,Docker,等等)运行mongod,它没有访问所有系统中可用的RAM,您必须设置storage.wiredTiger.engineConfig.cacheSizeGB的值小于容器使用的内存量。确切的数量取决于容器中运行的其他进程。请参阅 memLimitMB

要查看有关缓存和逐出的统计信息,请使用 serverStatus命令。该 wiredTiger.cache字段保存有关缓存和逐出的信息。

复制

...
"wiredTiger" : {
...
"cache" : {
"tracked dirty bytes in the cache" : <num>,
"bytes currently in the cache" : <num>,
"maximum bytes configured" : <num>,
"bytes read into cache" :<num>,
"bytes written from cache" : <num>,
"pages evicted by application threads" : <num>,
"checkpoint blocked page eviction" : <num>,
"unmodified pages evicted" : <num>,
"page split during eviction deepened the tree" : <num>,
"modified pages evicted" : <num>,
"pages selected for eviction unable to be evicted" : <num>,
"pages evicted because they exceeded the in-memory maximum" : <num>,,
"pages evicted because they had chains of deleted items" : <num>,
"failed eviction of pages that exceeded the in-memory maximum" : <num>,
"hazard pointer blocked page eviction" : <num>,
"internal pages evicted" : <num>,
"maximum page size at eviction" : <num>,
"eviction server candidate queue empty when topping up" : <num>,
"eviction server candidate queue not empty when topping up" : <num>,
"eviction server evicting pages" : <num>,
"eviction server populating queue, but not evicting pages" : <num>,
"eviction server unable to reach eviction goal" : <num>,
"pages split during eviction" : <num>,
"pages walked for eviction" : <num>,
"eviction worker thread evicting pages" : <num>,
"in-memory page splits" : <num>,
"percentage overhead" : <num>,
"tracked dirty pages in the cache" : <num>,
"pages currently held in the cache" : <num>,
"pages read into cache" : <num>,
"pages written from cache" : <num>,
},
...

有关某些关键高速缓存和逐出统计信息(例如wiredTiger.cache.bytes currently in the cachewiredTiger.cache.tracked dirty bytes in the cache)的说明,请参见wiredTiger.cache

要调整WiredTiger内部缓存的大小,请参阅 storage.wiredTiger.engineConfig.cacheSizeGB--wiredTigerCacheSizeGB。避免将WiredTiger内部缓存的大小增加到其默认值以上。

如何计算应用程序需要多少内存?

通过WiredTiger,MongoDB可以利用WiredTiger内部缓存和文件系统缓存。

从MongoDB 3.4开始,默认的WiredTiger内部缓存大小是以下两者中的较大者:

  • 50% of (RAM - 1 GB), or

  • 256 MB.

例如,在总共有4GB内存的系统上,WiredTiger缓存将使用1.5GB 内存(0.5 * (4 GB - 1 GB) = 1.5)。相反,总内存为1.25 GB的系统将为WiredTiger高速缓存分配256 MB,因为这是总内存的一半以上减去1 GB 。(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).

注意

在某些情况下,例如在容器中运行时,数据库的内存限制可能低于系统总内存。在这种情况下,此内存限制而不是系统总内存将用作最大可用内存。

要查看内存限制,请参阅hostInfo.system.memLimitMB

默认情况下,WiredTiger对所有集合使用Snappy块压缩,对所有索引使用前缀压缩。压缩默认设置可在全局级别配置,也可以在每个集合和每个索引创建期间单独进行设置。

WiredTiger内部缓存中的数据与磁盘上的格式使用不同的形式的数据格式:

  • 文件系统缓存中的数据与磁盘格式相同,包括对数据文件进行任何压缩的好处。操作系统使用文件系统缓存来减少磁盘I / O。

  • 加载到WiredTiger内部缓存中的索引的数据表示形式与磁盘格式不同,但是仍可以利用索引前缀压缩来减少n内存使用量。索引前缀压缩可从索引字段中删除通用前缀。

  • WiredTiger内部缓存中的集合数据是未压缩的,并使用与磁盘格式不同的表示形式。块压缩可以节省大量的磁盘存储空间,但数据解压缩才能由服务器操作。

通过文件系统缓存,MongoDB自动使用WiredTiger缓存或其他进程未使用的所有可用内存。

要调整WiredTiger内部缓存的大小,请参阅 storage.wiredTiger.engineConfig.cacheSizeGB--wiredTigerCacheSizeGB。避免将WiredTiger内部缓存的大小增加到其默认值以上。

注意

storage.wiredTiger.engineConfig.cacheSizeGB限制WiredTiger内部缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存,从而允许压缩的MongoDB数据文件保留在内存中。此外,操作系统将使用任何可用的内存来缓冲文件系统块和文件系统缓存。

为了容纳更多的内存使用者,您可能必须减小WiredTiger内部缓存的大小。

默认的WiredTiger内部缓存大小值假定每台计算机有一个mongod实例。如果单个机器包含多个MongoDB实例,则应减小设置以容纳其他mongod 实例。

如果你在一个容器(例如lxccgroups,Docker,等等)运行mongod,它没有访问所有系统中可用的内存,您必须将storage.wiredTiger.engineConfig.cacheSizeGB`的值设置为小于容器可用内存大小的值。确切的大小取决于容器中运行的其他进程。参见 memLimitMB

要查看有关缓存和缓存淘汰率的统计信息,请参阅wiredTiger.cache命令返回的serverStatus 字段。

分片群集诊断

成功维护分片集群的两个最重要的因素是:

通过确保为部署选择最佳的片键,并确保始终在当前资源饱和之前为集群添加额外的容量,可以避免分片遇到的大多数问题。继续阅读,查看您在生产环境中可能遇到的特定问题。

在新的分片集群中,为什么所有数据都保留在一个分片上?

您的集群必须具有足够的数据才能进行分片。分片的工作原理是在分片之间迁移数据块,直到每个分片具有大致相同数量的分块。

默认的块大小为64 MB。在集群中的大块不平衡量超过迁移阈值之前,MongoDB不会开始迁移 。此行为有助于防止不必要的块迁移降低整个集群的性能。

如果您刚刚部署了分片集群,请确保您有足够的数据使分片有效。如果没有足够的数据来创建八个以上的64 MB数据块,则所有数据将保留在一个分片上。降低块大小设置,或向集群添加更多数据。

作为一个相关问题,系统将仅在插入或更新时拆分块,这意味着,如果您配置了分片并且不继续执行插入和更新操作,则数据库将不会创建任何块。您可以等待,直到应用程序插入数据 手动拆分块

最后,如果片键的基数较低,则MongoDB可能无法在数据之间创建足够的拆分(chunk将无法继续分裂)。

为什么一个分片会在分片集群中会收到不均衡的流量?

在某些情况下,单个分片或集群的子集将接收不均衡的流量和工作负载。在几乎所有情况下,这都是因为片键无法高效地允许写缩放

您也可能有“hot chunks”。在这种情况下,您可以通过拆分然后迁移部分块来解决问题。

在最坏的情况下,您可能必须考虑重新分拆数据并选择其他片键 来更正此模式。

什么可以阻止分片集群均衡?

如果您刚刚部署了分片群集,则可能需要考虑针对新集群数据仍保留在单个分片上故障排除建议

如果集群最初是均衡的,但后来却出现了数据分布不均的情况,请考虑以下可能的原因:

  • 您已从集群中删除或移除了大量数据。如果添加了其他数据,则其片键的分配可能会有所不同。

  • 您的片键具有较低的基数, 并且MongoDB无法进一步拆分块。

  • 您的数据集增长速度超过了均衡器可以在集群中分发数据的速度。这种情况并不常见,通常是由于以下原因造成的:

    • 相对于数据增长的速度,这个均衡窗口太短。

    • 写操作分布不均,需要更多的数据迁移。您可能必须选择其他分片键才能解决此问题。

    • 分片之间的网络连接不良,这可能会导致需要很长时间才能完成数据块迁移。检查您的网络配置和分片之间的互连。

为什么块迁移会影响分片集群的性能?

如果迁移会影响您的集群或应用程序的性能,请根据影响的性质考虑以下选项:

1.如果迁移仅偶尔中断集群,则可以限制均衡窗口以防止高峰时段进行均衡活动。确保有足够的时间来防止数据再次失去均衡。

2.如果均衡器始终在迁移块而不利于整体集群性能:

您的片键还可能导致应用程序将所有写入指向单个分片。这种活动模式可能要求均衡器在写入数据后立即迁移大部分数据。请考虑使用提供更好写入扩展的片键重新部署集群。

原文链接:https://docs.mongodb.com/manual/faq/diagnostics/

译者:钟秋

update:小芒果