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