【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】 tidb v6.5.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
heap memory节点内存显示
查看TiDB-Runtime页面针对每个tidb实例内存分析
这个 gc-threadhold为啥会占用这么高内存？
监控显示主要内存分为heap memory ， process ，analyze 占用的大小，其中heap memory ，process占用比较多，实际内存占用，是看heap memory 还是process，这里process ，和heap 都使用20-30G，如何分析占用这么多内存是否合理
curl -G
http://ip:10080/debug/pprof/heap > pd.heap.prof
然后go tool pprof pd.heap.prof 查看占用内存高的，heap单个也不高
go tool pprof去导出对应实例的内存分析，占用内存不高
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
changpeng75
(Ti D Ber Aw K Xsgx O)
2
TiDB上的GC是Go语言的垃圾回收吧，看看Go的垃圾回收机制是MADV_DONTNEED还是MADV_FREE?
怎么查看看看Go的垃圾回收机制是MADV_DONTNEED还是MADV_FREE?
changpeng75
(Ti D Ber Aw K Xsgx O)
5
GO的GC机制现在默认是MADV_FREE，可以在TiDB Server启动前添加GODEBUG=madvdontneed=1。
GC 的运行由 GC leader 来控制。这里有十几个tidb实例，对外提供服务的tidb实例gc占用内存都在20G左右，没有对外提供服务的tidb实例内存在10G左右，差异有点大，正常应该是leader占用内存大吧
江湖故人
9
threadhold是阈值的意思，不是使用量，到这个位置GO语言会开始回收内存。
GO默认内存管理策略MADV_FREE比MADV_DONTNEED更懒，容易导致TiDB发生OOM，所以有人改环境变量用MADV_DONTNEED模式：
GODEBUG=madvdontneed=1
redgame
(Ti D Ber Pa Amoi Ul)
10
垃圾回收机制通过标记-清除算法和并发标记清除算法来实现内存的自动回收，确保程序运行过程中不会出现内存泄漏和内存溢出问题。
垃圾回收机制负责清理不再使用的数据，当程序中有大量数据更改时，垃圾回收可能会占用较高的资源。
