TiKV内存一直缓慢上涨

搬砖er · 2023 年11 月 10 日 09:02

【 TiDB 使用环境】生产环境
【 TiDB 版本】4.0.2
【复现路径】N/A
【遇到的问题：问题现象及影响】
表现：线上单独使用TiKV存储数据(raw格式)，没有使用TiDB。集群规模：3pd，15个TiKV节点。
TiKV运行一段时间后，每个TiKV节点内存都在缓慢上涨，并且超过block-cache配置值很多。block-cache配置内存20GB，实际TiKV占用内存40GB+。尝试切换pd 的leader后，TiKV内存马上恢复，但是一段时候后继续上涨。pd日志中，有大量leader changed 和operator timeout的日志，见附件。
该内存上涨的问题应该怎么解决。

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
tikv内存：

rocksdb block cache

pd的监控

pd的日志

TiKV内存的火焰图
mem

Billmay表妹 · 2023 年11 月 10 日 09:14

裸 kv 在社区中使用的人非常少，建议使用 tidb

社区中很少有实践的场景，也就基本上没有什么社区的小伙伴可以帮你解决你的问题

遇到问题的时候，你就只能靠自己了

Billmay表妹 · 2023 年11 月 10 日 09:15

根据您描述的情况，TiKV 节点的内存占用在一段时间后会缓慢上涨，并且超过了 block-cache 配置值。当切换 PD 的 leader 后，TiKV 的内存会立即恢复，但一段时间后又会继续上涨。同时，PD 的日志中出现了大量的 leader changed 和 operator timeout 的日志。

这种情况可能是由于 TiKV 节点的数据写入速度超过了其处理能力，导致内存占用不断增加。为了解决这个问题，您可以考虑以下几个方面的优化：

调整 TiKV 的配置参数：可以尝试调整 TiKV 的一些配置参数，以提高其处理能力和内存使用效率。例如，可以调整 raftstore.apply-pool-size 参数来增加应用层的并发度，或者调整 raftstore.store-pool-size 参数来增加存储层的并发度。此外，还可以根据实际情况调整 raftstore.raft-entry-max-size 和 raftstore.raft-log-gc-threshold 等参数，以减少 Raft 日志的大小和清理频率。
检查热点数据和查询：通过监控和日志分析，确定是否存在热点数据和频繁查询的情况。如果存在热点数据，可以考虑使用 TiKV 的 Region Split 功能将热点数据分散到多个 Region 中，以减轻单个 TiKV 节点的负载。如果存在频繁查询的情况，可以优化查询语句或增加 TiKV 节点的数量来分担负载。
检查硬件资源：确保 TiKV 节点所在的服务器具有足够的硬件资源，包括 CPU、内存和磁盘。如果硬件资源不足，可能会导致 TiKV 节点的性能下降和内存占用增加。可以通过监控工具来查看服务器的资源使用情况，并根据需要进行硬件升级或优化。
升级 TiKV 版本：如果您正在使用较旧的 TiKV 版本，可以考虑升级到最新的稳定版本。每个版本的 TiKV 都会有一些性能和稳定性的改进，可能会对您遇到的问题有所帮助。

另外，关于 PD 的 leader changed 和 operator timeout 的日志，这可能是由于 PD 集群的负载过重或网络问题导致的。您可以检查 PD 节点的资源使用情况和网络连接情况，确保 PD 集群正常运行。

最后，建议您在进行任何调整之前，先进行性能分析和监控，以便更好地了解系统的瓶颈和优化方向。

希望这些信息对您有帮助。如果您有任何进一步的问题，请随时提问。

搬砖er · 2023 年11 月 10 日 10:32

TiKV集群没有发生扩缩容的情况下,pd监控显示发生大量的remove-extra-replica，此情况是否正常?

Jellybean · 2023 年11 月 10 日 11:35

集群本身在做热点调度、数据均衡等情况，都会有这种情况出现。不过出现大量的，得关注一下是不是有明显热点问题

hey-hoho · 2023 年11 月 10 日 14:12

看着像region在频繁的选举，还存在move peer超时，确认下各tikv节点之间的通信有没有问题

像风一样的男子 · 2023 年11 月 11 日 01:09

你安装granfa监控了没，可以看下region调度情况

Kongdom · 2023 年11 月 11 日 02:14

leader changed

看上去是一直在切换leader

xfworld · 2023 年11 月 11 日 05:17

版本有点低了，条件允许的情况下，优先考虑升级
有可能是已知的Bug 导致的问题，但是太过久远了，难以查证了
未使用 tidb ，需要手动触发 compaction 来释放空间，这个可以查证下，是否有达成
leader 频繁选举，是不是环境有什么问题导致的？建议排查网络

我是咖啡哥 · 2023 年11 月 12 日 00:40

厉害了，不用TiDB也可以。
官方没提供这种用法吧？这是自己研究源码，这样用的吗？这样用有什么优势？或者是出于啥目的？还望大佬普及下！

zhanggame1 · 2023 年11 月 12 日 04:43

升级下版本试试

Kongdom · 2023 年11 月 12 日 14:44

目前是支持裸tikv使用的，还不支持裸tiflash，很期待裸tiflash

搬砖er · 2023 年11 月 13 日 02:00

业务的需求，不需要sql

搬砖er · 2023 年11 月 13 日 02:01

升级需要重启tikv，现在有个问题，tikv重启后leader不会迁移回去重启的节点，所以不敢升级了。

xfworld · 2023 年11 月 13 日 02:25

region leader 可以手动指定的，这个操作不麻烦
但问题是：干嘛非要指定 region 的 leader ？不让系统自动调度？

搬砖er · 2023 年11 月 13 日 03:01

没有手工指定，tikv节点重启后，系统自动调度，平衡各个节点的leader看起来是失效的。

xfworld · 2023 年11 月 13 日 04:33

哪就要查下了，还有个问题，就是节点之间的资源平衡的速度，和调度的能力有很大的关系…

或者，定位下，调度是否在被执行…

路在何chu · 2023 年11 月 13 日 06:09

版本太低了，升级吧，也没有啥查询

路在何chu · 2023 年11 月 13 日 06:10

哪怕你搞一个tidb节点也行啊，放那不用也行

芮芮是产品 · 2023 年11 月 21 日 07:32

几乎没人懂你的需求