告警TiDB heap memory usage is over 10 GB,是建议阀值调高,如何看占用内存比较高的

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】 tidb v6.5.0
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
是不是偶尔告警TiDB heap memory usage is over 10 GB
不知道下面是不是没有抓住问题点
go tool pprof pd.heap.prof
(pprof) top
Showing nodes accounting for 3071.46MB, 71.99% of 4266.26MB total
Dropped 991 nodes (cum <= 21.33MB)
Showing top 10 nodes out of 284
flat flat% sum% cum cum%
702.25MB 16.46% 16.46% 1435.07MB 33.64% github.com/pingcap/tidb/store/copr.(*copIteratorWorker).handleCopResponse
612.81MB 14.36% 30.82% 612.81MB 14.36% github.com/dgraph-io/ristretto.(*expirationMap).update
367.52MB 8.61% 39.44% 367.52MB 8.61% github.com/pingcap/kvproto/pkg/metapb.(*Region).Unmarshal
351.68MB 8.24% 47.68% 351.68MB 8.24% github.com/pingcap/tidb/store/copr.coprCacheBuildKey
299.52MB 7.02% 54.70% 299.52MB 7.02% github.com/tikv/client-go/v2/internal/locate.newRegion
257.05MB 6.03% 60.73% 257.05MB 6.03% sync.(*Pool).pinSlow
181.01MB 4.24% 64.97% 238.02MB 5.58% github.com/tikv/client-go/v2/internal/locate.(*RegionCache).insertRegionToCache
111.02MB 2.60% 67.57% 350.53MB 8.22% github.com/pingcap/kvproto/pkg/pdpb.(*GetRegionResponse).Unmarshal
98MB 2.30% 69.87% 98MB 2.30% github.com/tikv/client-go/v2/util/codec.decodeBytes
90.59MB 2.12% 71.99% 90.59MB 2.12% github.com/pingcap/tidb/util/chunk.newFixedLenColumn

我目前的问题是,是调高告警阀值,还是要继续分析占用内存的SQL

【附件:截图/日志/监控】

日志中没有expensive SQL

1 个赞

看看慢sql呢是不是很多

关注一下,静待有缘人。

慢SQL平时都会有,只是消耗heap memory 的需要分析,如何分析

可以看下heap关系图
TiDB Dashboard 监控关系图 | PingCAP 文档中心

想看内存占用高的,就慢查询、SQL语句分析,优化SQL后能减少内存占用,想不告警,就调整阈值吧

内存最好扩一下,官方推荐测试环境都不止4G呢[1].

你搞错了,我256G内存

有内存暴涨问题,先分析是不是SQL有问题。
看看tidb.log里有没打印expensive query 相关日志。如果是执行成功的SQL,还可以看看慢日志,看执行计划什么的。

expensive query 日志和慢查询日志的区别是,慢查询日志是在语句执行完后才打印,expensive query 日志可以将正在执行的语句的相关信息打印出来。当一条语句在执行过程中达到资源使用阈值时(执行时间/使用内存量),TiDB 会即时将这条语句的相关信息写入日志。

看下呢
select * from information_schema.cluster_memory_usage;

请看我前面已经说了,日志没有 expensive SQL

查下最近慢查询,看有没有优化空间

select
	query sql_text,
	mnt,
	max_mem_max,
	sum_query_time,
	mnt as executions,
	avg_query_time,
	avg_proc_time,
	avg_wait_time,
	max_query_time,
	avg_backoff_time,
	Cop_proc_addr,
	digest,
	(case
		when avg_proc_time = 0 then
'point_get or commit'
		when (avg_proc_time > avg_wait_time
		and
avg_proc_time > avg_backoff_time) then
'coprocessor_process'
		when (avg_backoff_time > avg_wait_time
		and
avg_proc_time < avg_backoff_time) then
'backoff'
		else
'coprocessor_wait'
	end) as type
from
	(
	select
	    query ,
		count(*) mnt,
	    max(mem_max) max_mem_max,
		avg(query_time) avg_query_time,
		avg(process_time) avg_proc_time,
		avg(wait_time) avg_wait_time,
		max(query_time) max_query_time,
		sum(query_time) sum_query_time,
		max(digest) digest,
		max(Cop_proc_addr) Cop_proc_addr,
		avg(backoff_time) avg_backoff_time
	from
		information_schema.cluster_slow_query
	where
		time >= '2024-01-17 00:00:00'  
	group by query ) t
order by
	max_mem_max desc
limit 10;

image

内存很富余,调高阈值吧 :face_with_open_eyes_and_hand_over_mouth:

设置大点。

gc thread 会占用内存19G

这个按照自己实际 情况决定,内存充足就不用担心,如果在一个合适的值情况下,有报警,那就查是什么导致的