多谢回复， 我们在分析确认是 streaming 导致的问题后， 发现我们有在配置文件中开启 enable-streaming: true， 把这个选项关闭到现在差不多30多小时，内存占用基本在300M以内，现在看来效果还不错。 但这个 enable-streaming 选项在文档中好像找不到了，不再支持了吗？那是不是要考虑忽略配置文件这个参数？ 关于日志，因我们tidb部署在k8s集群中，目前只做了 slowlog 日志收集，tidb应用日志在重启后就会丢失，所以我只下载到重启后一段时间的日志， 如有需要我发您邮箱。

goroutine 在监控中也是在持续上升： [WX20210816-161458] 我们目前分析 goroutine，发现卡住的 goroutine 最终都到了 grpc 这里： goroutine 32574899 [select, 346 minutes]: google.golang.org/grpc.newClientStream.func5(0xc000792000, 0xc02e28b9e0, 0x38d3be0, 0xc05116b680) /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/…

我们仔细分析后，感觉这个 goroutine 应该不正常，里面有数万的运行中的 grpc 连接，部分如下： [WX20210813-143931] 图上的时间长的一千多分钟， 短的一两分钟的也有， 完整 groutine 上面 profile.zip 有，这里再单独上传一下： goroutine.zip (2.2 MB) 这应该是 TiDB 与 TiKV 的 grpc 连接发生了线程泄漏的问题，我们目前没有找到如何配置超时时间，暂时也不清楚触发条件

我们目前配置的内存限制为 256M mem-quota-query = 268435456 oom-action = "cancel" 我再提供一个刚重启一小时左右的 profile， 目前内存占用约300M profile2.zip (588.0 KB) 慢查询我们一直在优化， 现在的比半年前已经减少了超过一半， 但 tidb 这个内存问题没有明显缓解，目前我们系统select峰值 ops 800 多， 日常200-400， 慢查询占总量应该还是比较低的 [WX20210812-151103] 关于 SQL DIGEST 我再研究下。 @Kongdom 我有多次尝试分别连各…

我现在也怀疑是不是 http 连接有泄漏的情况， 可关键是这 http2client 是哪里的我们搞不太清楚。 访问 tidb 方面我们应用只连接 4000 端口， k8s 健康检测也是 tcpSocket 4000， 只有 prometheus 会连接 10080 获取监控数据

一开始使用的是默认值未做变更， 后来有尝试变更， 现在 # VARIABLE_NAME VARIABLE_VALUE tikv_gc_leader_uuid 5eccaf919100004 tikv_gc_leader_desc host:diiing-tidb-2, pid:1, start at 2021-08-11 09:05:35.814607793 +0800 CST m=+0.138338731 tikv_gc_leader_lease 20210812-13:51:35 +0800 tikv_gc_enable true tikv_gc_run_…

非常感谢您对此问题的持续关注， 服务器层面CPU起来是正常的波动，这是tidb节点CPU监控图： [WX20210812-131230] 其他节点波动类似， 但内存监控图是这样的： [WX20210812-131430] 这个问题应该是从我们切换到 tidb 就一直存在， 最开始的版本是4.0.4，到现在差不多一年了。 在此期间我们尝试了很多办法，内存限制也从一开始的2G到4G再到现在专用节点，重启频率低了，但问题一直存在，很是难受…

目前我们没有使用 dumpling 进行备份， 另外发生时间点是随机的，内存满了就会重启。 内存突增大部分发生在7-9点， 这倒也是我们业务高峰， 但我们分析了很久也没发现异常SQL。其他时间也在缓慢逐渐上升。

抱歉， 昨天写了一半被拉去开会搞到半夜。 当时指的是重启时吗？ 一方面我们的日志收集有点儿问题，只收集了 slowlog，所以 tidb 日志重启后就没有了。 二一个这是内存持续增长直到最后超出限制，所以压倒骆驼的最后一根稻草可能不是真正的原因。 本来我想把完整日志传上来， 但后来看里面还是有不少敏感信息，发公开场合不太好，我尝试贴部分怀疑的日志，如需完整日志不知是否有不公开方式来进行？ [2021/08/11 16:09:08.190 +08:00] [WARN] [client_batch.go:638] ["wait response is cancelled"] [to=di…

我们也怀疑过这个问题，这个但从监控来看， 连接数并没有明显的波动 [WX20210811-172945] 图中几个明显的锯齿是由 TiDB 重启导致的。 连接的服务全部使用 java， 连接池以 Ali Druid 为主， 其他不同连接池也有，但涉及服务较多，尚未一一统计