GaussDB others内存比较高的场景

others内存高指的是pv_total_memory_detail中的others_used_memory占用比较高的内存的情况。

others内存的计算方式：

gaussdb进程占用的内存 - dynamic_used_memory- shared_used_memory- cstore_used_memory - shared_used_memory后的值。

others内存一般是内核直接通过malloc申请的内存，或者第三方库中申请的内存。

1.已知的会导致others内存高的场景

1）协同分析场景下，cn的ssl打开。该问题是由于建联过程中内存泄漏。

版本：到目前的8.1.3版本还有问题。

确认方法：

show ssl; (值为on)

select * from pg_foreign_server;

上图是没有协同分析的输出，如果有协同分析业务的话，会多出来几条记录。

规避措施：

将cn的ssl参数关闭

gs_guc set -Z coordinator -N all -I all -c "ssl=on"

设置好后，重启集群生效。

2）连接数过多导致的others内存占用高，需要清理idle状态的空闲连接。此场景others内存一般不会涨的很夸张。

确认方法：当作业都停止后，others依然过高，通过ps -T -p <pid>、gstack或gcore，获取others过高的cn或dn中的线程数量，确认线程数量超过100+。

实验室已模拟复现，在300连接时占用others内存约1.7G，1200连接时占用others内存约5.7G。

规避措施：

结合业务情况，现场定期（如每小时）通过主动执行clean connection进行规避。

CLEAN CONNECTION TO ALL FOR DATABASE dbname;

3）透明大页打开

http://3ms.huawei.com/km/blogs/details/8366421

确认方法：

grep Huge /proc/meminfo

AnonHugePages 过大说明有问题。

4）Kerberos内存泄漏

版本：

8.0版本：已不存在该问题。

6.5.1版本：查看gaussdb版本，客户现场的版本编译时间晚于2019-09-25，不会有该问题。

C80版本：由于kerberos低版本本身有少量内存泄漏，故不能完全避免，但可通过关闭开关的方式规避。客户现场的版本编译时间晚于2019-12-14，会显著改善泄漏的情况（预计可降低1000倍）。

确认方法：

5）LLVM内存泄漏

版本：8.0版本已修复 6.5.1版本暂未回合 C80的808补丁内已回合

确认方法：

1. 查看LLVM总开关是否打开show enable_codegen;

2. 查看客户系统的表结构是否包含列存表。列存表才会触发LLVM。

3. 针对步骤2分析的列存表结合cn日志分析涉及的sql语句。通过explain performance分析改语句是否走到

6）others内存定位方法，jemalloc heap profiling功能

版本：810版本（2020年9月30日）之后的版本支持，需要替换jemalloc的so文件。

替换方法：

1）jemalloc的带有profiling功能的so文件放在$GAUSSHOME/lib/jeprof文件里边。

将这个so放到$GAUSSHOME/lib/下。

2）添加环境变量MALLOC_CONF

export MALLOC_CONF=prof:true,lg_prof_sample:10

lg_prof_sample 代表每分配2^10字节采样一次，采样频率高了之后会有性能影响。

3）kill om_monitor进程，重新加载环境变量，等待om_monitor进程被自动重新拉起。

4）停止集群，或者kill需要监控的实例。

5）检查是否替换成功。

上图中输出t代表成功。

定位方法：

1.跑一会之后查看pv_total_memory_detail的others内存涨的比较高的时候，调用

select * from pv_memory_profiling(2);

之后会在该实例的数据目录输出一个文件

2.获取jemalloc的统计信息。

select * from pv_memory_profiling(3);

在该实例的数据目录输出一个文件

可以将现场的文件取回进行分析。

jeprof --show_bytes --pdf gaussdb(路径) heap(文件) > heap.pdf(自行命名)

通过jeprof工具生成pdf文件，jeprof工具在$GAUSSHOME/bin目录下。

输出的pdf文件如下所示

之后就可以看到是哪个函数占用的内存比较多，从而排查内存占用是否合理。