【问题】 当前遇到的问题
所有的TiDB节点,不管32G还是64内存,TiDB节点内存不断上升最后服务重启,tidb.log
【业务影响】
系统表现不稳定:节点重启期间无法提供服务,造成服务中断
【TiDB 版本】
TiDB-v5.0.0
【问题】 当前遇到的问题
所有的TiDB节点,不管32G还是64内存,TiDB节点内存不断上升最后服务重启,tidb.log
参考一下这个帖子
收到~谢谢 这边试下
您好,
1,第一步set global tidb_analyze_version = 1;执行了,不过SHOW GLOBAL VARIABLES like ‘%tidb_analyze_version%’;通过这个是没有结果的
2,因为第2步没有结果,第2,3步无需执行,
3,现在逐步把所有tidb-server重启试下
https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_analyze_version-从-v510-版本开始引入
这是 5.1.0开始引入的,5.0还没有.。
最近 oom 的问题发生了好几期,已经反馈到版主那里了,完善解决方案可能要等一段时间。
好的,
那这边需要提供什么不
然后,是临时的解决方案也行,这边如何去定位、操作呢
还有,请问下, 使用 tiup ctl tidb
命令来获取 TiDB Control工具如何指定版本,指定什么版本,前面SHOW GLOBAL VARIABLES like ‘%tidb_analyze_version%’;没有结果,想通过命令查看遇到问题
tiup ctl tidb报
麻烦提供一下 tidb-server 的日志吧,另外,在 内存较高的时候,提供一下 这个命令的结果,
curl http://{TiDBIP}:10080/debug/zip?seconds=60 --output debug.zip
好的 稍等
有个情况补充下,会有不定时的MySQL has gone away报错,下面是其中一台服务器的报错分布情况,
0926 15 300(9月26号15-16点 报错个数 300)
0926 16 0
0926 17 371
0926 18 16
0926 19 656
0926 20 21340
0926 21 47
0926 22 521
0926 23 186
0927 00 24559
0927 01 21567
0927 02 215
0927 03 0
0927 04 138
0927 05 98
0927 06 8872
0927 07 0
0927 08 2619
0927 09 128
0927 10 1654
0927 11 0
0927 12 60
0927 13 190
0927 14 3215
0927 15 803
MySQL has gone away,多是 服务器重启或连接断开导致
服务重启可能会有,不全是,判断依据报错在一天中大多数时间都有,但是服务重启并没这么频繁,一次会要超过一天
连接断开这个怎么要怎么定位,如何优化呢,之前并没有这样的情况
就得看 tidb- server 的日志了(内存的问题,这边先分析一下)
目前怀疑是内存泄露,原因就是说的:mysql.stats_fm_sketch 这个表的数据没有及时删除,每次 load 都会读取所有历史版本导致的。临时解决办法说:先把stats_fm_sketch清空(这个表的数据会重新生产的,正常这个表大小和stats_histograms 行数差不多)
收到 谢谢~ 这边试下
请问 这个跟是否有负载均衡有关是吗,怎么关联上的
MySQL has gone away
这边要提供tidb-server日志么
mysql.stats_fm_sketch 这个表的数据原来是8w+,清除后,内存上是有效果的,现在是604,并没有跟stats_histograms 行数差不多
只是,慢语句也出来了(从原来1s内到现在3s),会不会也是因为重新生产不及时
您好 经过这几天的观察,stats_fm_sketch的数据清除后内存没出现之前的情况,只是慢语句执行时间比之前长的情况是持续出现的,这相当于出现一个新问题,请问是否有方法先快速重新生产清除的表数据(目前表中记录数量恢复到9621)