TiDB_2021-10-19T06_21_48.710Z.json (5.5 MB) TiKV-Details_2021-10-19T06_15_11.656Z.json (25.3 MB) Overview_2021-10-19T06_06_03.979Z.json (2.8 MB)
您好 这个是您需要的监控信息 大概15号的23:03分内存开始飙升 后面23点30多分重启了下tidb节点 恢复了正常
看监控感觉像是跟GC有关,根本原因还得等大神来看
TiDB_2021-10-19T06_21_48.710Z.json (5.5 MB) TiKV-Details_2021-10-19T06_15_11.656Z.json (25.3 MB) Overview_2021-10-19T06_06_03.979Z.json (2.8 MB) 您好 这个是监控的快照 大概15号的23:03分内存开始飙升 后面23点30多分重启了下tidb节点 恢复了正常
问题点的tidb前后日志发一下
这是全部的日志?
tiup cluster 看下拓扑,你这个是混合部署?
10-12是部署TiDB,PD 各三节点 10是tiup中控机 12上还有prometheus Grafana Alertmanager 13-15是部署tikv
tidb_1015.log (7.3 MB) 这份是当天的完整日志 请查收 差不多在2021/10/15 23:03 内存开始突增 [2021-10-15 23:15:57]收到TiDB_monitor_keep_alive,TiDB monitor_keep_alive error] 告警。23点33分左右重启tidb 恢复正常
没有别的特殊操作的 一个集群是有定时的load导数据任务 一个集群是高并发的读表
起来像是 ddlHistoryJobHandler.ServeHTTP 这个地方导致的内存暴增 是不是应用端拉了全量的 ddl history, 如果 ddl 很多的话且有并法的话, 确实会有这个问题,麻烦帮忙确认下,多谢。
好的 我们确认下 感谢
现在每天ddl不多的,就几个表同步数据的时候,会删表建表。看了information_scheam.ddl_jobs表,这个表也才14700条记录。
您好 应用的权限只有对库的增删改查呢 这个全量的 ddl history 应该是没有权限拉
是否有类似操作?如果有 25 的操作,建议使用 26 limit 限制。
https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md
您好 我问了下 没做过这种操作的