抱歉， 昨天写了一半被拉去开会搞到半夜。
当时指的是重启时吗？ 一方面我们的日志收集有点儿问题，只收集了 slowlog，所以 tidb 日志重启后就没有了。
二一个这是内存持续增长直到最后超出限制，所以压倒骆驼的最后一根稻草可能不是真正的原因。
本来我想把完整日志传上来， 但后来看里面还是有不少敏感信息，发公开场合不太好，我尝试贴部分怀疑的日志，如需完整日志不知是否有不公开方式来进行？
[2021/08/11 16:09:08.190 +08:00] [WARN] [client_batch.go:638] ["wait response is cancelled"] [to=diiing-tikv-0.diiing-tikv-peer.tidb.svc:20160] [cause="context canceled"]
[2021/08/11 16:09:08.190 +08:00] [WARN] [client_batch.go:638] ["wait response is cancelled"] [to=diiing-tikv-3.diiing-tikv-peer.tidb.svc:20160] [cause="context canceled"]
[2021/08/11 16:09:13.487 +08:00] [INFO] [coprocessor.go:1034] ["[TIME_COP_WAIT] resp_time:307.495003ms txnStartTS:426945898889084938 region_id:1645916 store_addr:diiing-tikv-2.diiing-tikv-peer.tidb.svc:20160 kv_wait_ms:289"] [conn=52853]
[2021/08/11 16:09:13.514 +08:00] [INFO] [coprocessor.go:1034] ["[TIME_COP_WAIT] resp_time:325.388035ms txnStartTS:426945898889084938 region_id:1649540 store_addr:diiing-tikv-2.diiing-tikv-peer.tidb.svc:20160 kv_wait_ms:308"] [conn=52853]
这几个看起来是因超时而取消了请求。
回一下 @xfworld， 慢查询是我们尝试的首要目标， 但目前接入这个TiDB 的服务较多， 业务较杂， 难以完全解决， 我们目前每天超过1秒的慢查询有约2000条， 超过5秒的有约50条， 同时为了避免异常SQL导致问题我们设置了 MAX_EXECUTION_TIME 为15秒， 但这个内存问题依旧没有改善