【 TiDB 使用环境】生产环境
【遇到的问题：问题现象及影响】
当前的TiDB集群中一个TiDB节点的CPU非常高且有较大波动，其他节点CPU都非常稳定，基本不超过100%
Top SQL中的信息比较奇怪，一个系统内部空表的查询占用了一半时间
Slow Query中并没有业务查询，全都是analyze
最后排查CPU的使用，看起来主要是GC占大头，但不知道该如何排查是什么操作引起了高GC了
麻烦大佬给一些建议，看看怎么继续排查
【资源配置】
Top SQL中的信息比较奇怪，一个系统内部空表的查询占用了一半时间
Slow Query中并没有业务查询，全都是analyze
最后排查CPU的使用，看起来主要是GC占大头，但不知道该如何排查是什么操作引起了高GC了
麻烦大佬给一些建议，看看怎么继续排查
【资源配置】
看一下analyze的配置，建议控制下analyze的时间范围，也可以对大表采用脚本定时analyze的情况
我用SHOW GLOBAL VARIABLES LIKE '%analyze%';查看了配置，用的都是默认的analyze配置，如下
tidb_analyze_partition_concurrency 2
tidb_analyze_skip_column_types json,blob,mediumblob,longblob
tidb_analyze_version 2
tidb_auto_analyze_end_time 23:59 +0000
tidb_auto_analyze_partition_batch_size 1
tidb_auto_analyze_ratio 0.5
tidb_auto_analyze_start_time 00:00 +0000
tidb_enable_analyze_snapshot OFF
tidb_enable_auto_analyze ON
tidb_enable_fast_analyze OFF
tidb_max_auto_analyze_time 43200
tidb_mem_quota_analyze -1
tidb_persist_analyze_options ON当前什么版本 ？
7.5.0版本
可以先升级 v7.5.1 试试
这上面不会列出所有的analyze,你可以试下先调整analyze的时间范围，比如凌晨0点-8点，然后观测下show analyze status和cpu的情况，如果下来了就能定位到这个问题，毕竟这个更改很简单，影响小
另外看一下 tidb_auto_analyze_partition_batch_size 的值，建议调大，最新的tidb里面这个是 8192，并准备淘汰了
可以的，我先试试看
好的，我看一下
检查一下那个表的类型，是不是有比较大的列
tidb_analyze_skip_column_types 看一下这个参数，现在最新里面这个值的默认值是 json,blob,mediumblob,longblob,mediumtext,longtext
所以检查一下有没有 text 类型
我看到目前是没有的
tidb_analyze_skip_column_types json,blob,mediumblob,longblob
我现在通过时间范围把analyze停止了，先观察一下CPU是否会下降
目前已经把analyze暂停了，不过CPU依然很高，看起来应该和analyze没有太大的关系
我发现只要gc-threshold上升，GC不被触发，则CPU就会立刻下来，但奇怪的是为什么gc-threshold会不断变化？
因为按照官方文档
当 TiDB 的内存使用达到
tidb_server_memory_limit值 *tidb_server_memory_limit_gc_trigger值时，则会主动触发一次 Golang GC
我理解gc-threshold应该是Server Memtidb_server_memory_limittidb_server_memory_limit_gc_trigger，是一个固定值吧？
而且gc-threshold和使用内存大小一致，应该也是直接原因，不断触发GC导致CPU居高不下
tidb-server 内存长时间保持在阈 tidb_server_memory_limit * tidb_server_memory_limit_gc_trigger 值以上时，会触发 issue
unexpected cpu usage caused by tidb_server_memory_gc_trigger · Issue #48741 · pingcap/tidb · GitHub
导致 CPU 长时间处于较高使用状态。
在7.5.1 版本才解决。你可以升级试试。
2 个赞
好的，不过我还是比较好奇这个计算的过程，例如根据上面的图，是无法得到对应的gc-threshold的
| Description | Value |
|-----------------------|-------|
| Server Mem | 62.4 |
| alloc-from-os | 49.6 |
| estimate-inuse | 18.7 |
| go-memstats-inuse | 37.3 |
| estimate-garbage | 18.7 |
| reserved-by-go | 2.7 |
| used-by-go | 1.6 |
| gc-threshold | 37.3 |
|-----------------------|-------|
49.6 * 0.8 * 0.7 = 27.776 != 37.3升级最新版那就对了
还有把 tidb_enable_historical_stats 关闭，那个有 OOM 风险