FAQ: MongoDB诊断
在本页面
本文档提供了常见诊断问题的答案。
复制
sudo grep mongod /var/log/messages
sudo grep score /var/log/messages
（译者注：tcp keepalive时间设置，主要用来探测连接对端是否还存活。当你建立一个TCP连接的时候，便有一组定时器与之绑定在一起。其中 的一些定时器就用于处理keepalive过程。当keepalive定时器到0的时候，我们便会给对端发送一个不包含数据部分的keepalive探测包。如果我们收到了keepalive探测包的回复消息，那么我们就可以断定连接依然是OK的。如果我们没有收到对端keepalive探测包的回复消息，我们便可以断定连接已经不可用，进而可以采取一些措施。）
在客户端和服务器之间或者分片集群或副本集的成员之间，如果通信中遇到网络超时或套接字错误，请检查受影响系统的_TCP keepalive值_。
许多操作系统默认将_TCP keepalive值_设置为
7200秒（两个小时）。对于MongoDB，通常情况下，保持较短时间值（120几秒钟（两分钟）），您将获得更好的结果。- Linux
- Windows
- macOS
- 要在Linux上查看keepalive设置，请使用以下命令之一：复制sysctl net.ipv4.tcp_keepalive_timeOr:
复制
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>
- 要在Windows上查看keepalive设置，请使用以下命令之一：
复制
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime
注册表值默认情况下不存在。如果没有该值，则使用系统默认值，以
7200000毫秒为单位或 0x6ddd00以十六进制表示。- 要改变
KeepAliveTime值，在管理员使用以下命令提示符，其中以十六进制（例如，表示120000为0x1d4c0）：
复制
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>
Windows用户应该查看KeepAliveTime上的Windows Server Technet章节，以获取有关在Windows系统上为MongoDB部署设置keepalive的更多信息。
mongod和mongos会忽略大于或等于_600000_毫秒（10分钟）的 keepalive值 。- 要在macOS上查看keepalive设置，请使用以下命令之一：
复制
sysctl net.inet.tcp.keepidle
该值以秒为单位测量。
- 要更改该
net.inet.tcp.keepidle值，可以使用以下命令，以毫秒为单位提供一个 ：
复制
sudo sysctl net.inet.tcp.keepidle=<value>
注意
在macOS 10.15 Catalina中，Apple不再允许配置该
net.inet.tcp.keepidle选项。如果您在MongoDB日志中看到大量的连接和重新连接消息，则说明客户端与MongoDB服务器经常连接和断开。对于不使用请求池的应用程序（例如CGI），这是正常的行为。考虑使用FastCGI，Apache模块或其他某种持久性应用程序服务器来减少连接开销。
- 操作执行时间
- 内存使用情况
- CPU使用率
- 操作计数
在MongoDB Cloud Manager和 在MongoDB的企业提供先进的内部部署解决方案的Ops Manager包括监控功能，其收集运行的MongoDB部署数据，并提供基于数据的可视化和警报。
不需要。
如果缓存没有足够的空间来加载其他数据，则WiredTiger会将页面从缓存中逐出以释放空间。
注意
该
storage.wiredTiger.engineConfig.cacheSizeGB限制WiredTiger内部缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存，从而允许压缩的MongoDB数据文件保留在内存中。此外，操作系统将使用任何可用的RAM来缓冲文件系统块和文件系统缓存。为了容纳更多的内存使用者，您可能必须减小WiredTiger内部缓存的大小。
如果你在一个容器（例如
lxc， cgroups，Docker，等等）运行mongod，它_没有_访问所有系统中可用的RAM，您必须设置storage.wiredTiger.engineConfig.cacheSizeGB的值小于容器使用的内存量。确切的数量取决于容器中运行的其他进程。请参阅 memLimitMB。复制
...
"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 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内部缓存大小是以下两者中的较大者：
- 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).注意
在某些情况下，例如在容器中运行时，数据库的内存限制可能低于系统总内存。在这种情况下，此内存限制而不是系统总内存将用作最大可用内存。
默认情况下，WiredTiger对所有集合使用Snappy块压缩，对所有索引使用前缀压缩。压缩默认设置可在全局级别配置，也可以在每个集合和每个索引创建期间单独进行设置。
WiredTiger内部缓存中的数据与磁盘上的格式使用不同的形式的数据格式：
- 文件系统缓存中的数据与磁盘格式相同，包括对数据文件进行任何压缩的好 处。操作系统使用文件系统缓存来减少磁盘I / O。
- 加载到WiredTiger内部缓存中的索引的数据表示形式与磁盘格式不同，但是仍可以利用索引前缀压缩来减少n内存使用量。索引前缀压缩可从索引字段中删除通用前缀。
- WiredTiger内部缓存中的集合数据是未压缩的，并使用与磁盘格式不同的表示形式。块压缩可以节省大量的磁盘存储空间，但数据解压缩才能由服务器操作。
通过文件系统缓存，MongoDB自动使用WiredTiger缓存或其他进程未使用的所有可用内存。
要调整WiredTiger内部缓存的大小，请参阅
storage.wiredTiger.engineConfig.cacheSizeGB和 --wiredTigerCacheSizeGB。避免将WiredTiger内部缓存的大小增加到其默认值以上。注意
该
storage.wiredTiger.engineConfig.cacheSizeGB限制WiredTiger内部缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存，从而允许压缩的MongoDB数据文件保留在内存中。此外，操作系统将使用任何可用的内存来缓冲文件系统块和文件系统缓存。为了容纳更多的内存使用者，您可能必须减小WiredTiger内部缓存的大小。
如果你在一个容器（例如
lxc， cgroups，Docker，等等）运行mongod，它_没有_访问所有系统中可用的内存，您必须将storage.wiredTiger.engineConfig.cacheSizeGB`的值设置为小于容器可用内存大小的值。确切的大小取决于容器中运行的其他进程。参见 memLimitMB。成功维护分片集群的两个最重要的因素是：
您的集群必须具有足够的数据才能进行分片。分片的工作原理是在分片之间迁移数据块，直到每个分片具有大致相同数量的分块。
您也可能有“hot chunks”。在这种情况下，您可以通过拆分然后迁移部分块来解决问题。
如果集群最初是均衡的，但后来却出现了数据分布不均的情况，请考虑以下可能的原因：
如果迁移会影响您的集群或应用程序的性能，请根据影响的性质考虑以下选项：
1.如果迁移仅偶尔中断集群，则可以限制均衡窗口以防止高峰时段进行均衡活动。确保有足够的时间来防止数据再次失去均衡。
2.如果均衡器始终在迁移块而不利于整体集群性能：
译者：钟秋
update:小芒果
最近更新 1yr ago