前言

在日常数据库的使用中,难免会遇到一些内存问题。此次博文主要向大家分享一些华为云数仓GaussDB(DWS)内存的基本框架以及基本视图的使用,以便遇到内存问题后可以有一个基本的判断。

注意,本篇博文基于华为云数仓GaussDB(DWS) 8.0版本,其他版本细节上或许稍有不同。

内存常用视图

1. PV_TOTAL_MEMORY_DETAIL视图

该视图会展示当前数据库节点的内存使用信息,单位为MB。

视图中个字段的含义:nodename:节点名称,memorytype:内存类型,memorymbytes:对应内存类型的大小。

常用的内存类型有以下几种:

  • max_process_memory:取自GUC参数max_process_memory的配置,表示一个数据库节点最大可使用的物理内存。
  • process_used_memory:取自/proc/pid/statm(第二个值) * pagesize,pid替换为当前节点所在的进程号。表示当前节点所处进程已使用的内存。
  • max_dynamic_memory:由下面公式计算而来,表示Gaussdb内核所能使用的最大内存。
  • max_dynamic_memory = max_process_memory- max_cstore_memory - udf_reserved_memory - max_shared_memory ;
  • dynamic_used_memory:GaussDB内核已使用内存,由GaussDB内存管理在申请内存时统计而来。
  • dynamic_peak_memory:GaussDB内核使用内存峰值,由GaussDB内存管理在申请内存时统计而来。
  • dynamic_used_shrctx:GaussDB内核已使用线程间共享内存上下文内存大小,由GaussDB内存管理在申请内存时统计而来。
  • dynamic_peak_shrctx:GaussDB内核已使用线程间共享内存上下文内存峰值,由GaussDB内存管理在申请内存时统计而来。
  • max_shared_memory:进程间最大共享内存大小
  • shared_used_memory:进程间已使用共享内存大小,由/proc/pid/statm(第三个值) * pagesize值统计而来。
  • max_cstore_memory:列存允许的最大使用内存,由GUC参数cstore_buffers配置。
  • cstore_used_memory:列存已使用内存,一般包含列存或HDFS使用过程中所消耗的内存。
  • other_used_memory:通常表示除去GaussDB内核使用的内存以外的内存使用,通常是三方库使用所消耗的内存,例如LLVM,Kerberos等。
postgres=# select * from  PV_TOTAL_MEMORY_DETAIL;
nodename | memorytype | memorymbytes
--------------+-------------------------+--------------
coordinator1 | max_process_memory |
coordinator1 | process_used_memory |
coordinator1 | max_dynamic_memory |
coordinator1 | dynamic_used_memory |
coordinator1 | dynamic_peak_memory |
coordinator1 | dynamic_used_shrctx |
coordinator1 | dynamic_peak_shrctx |
coordinator1 | max_shared_memory |
coordinator1 | shared_used_memory |
coordinator1 | max_cstore_memory |
coordinator1 | cstore_used_memory |
coordinator1 | max_sctpcomm_memory |
coordinator1 | sctpcomm_used_memory |
coordinator1 | sctpcomm_peak_memory |
coordinator1 | other_used_memory |
coordinator1 | gpu_max_dynamic_memory |
coordinator1 | gpu_dynamic_used_memory |
coordinator1 | gpu_dynamic_peak_memory |
coordinator1 | pooler_conn_memory |
coordinator1 | pooler_freeconn_memory |
coordinator1 | storage_compress_memory |
coordinator1 | udf_reserved_memory |
( rows)

2. PV_SESSION_MEMORY_DETAIL视图

华为云数仓GaussDB(DWS)的内存管理框架沿用了之前的内存上下文的思路。在PV_SESSION_MEMORY_DETAIL的视图中,将会统计各线程的内存上下文维度统计的内存使用情况。

视图中个字段的含义如下:

Sessid:表示Session ID,由线程启动时间+线程标识拼接而来。

Sesstype:线程名称

Contextname:内存上下文名称。

Level:内存上下文层级。

Parent:父内存上下文名称。

Totalsize:当前内存上下文内存大小

Freesize:当前内存上下文已释放内存大小

Usedsize:当前内存上下文已使用大小。

postgres=# select * from PV_SESSION_MEMORY_DETAIL order by totalsize desc;
sessid | sesstype | contextname | level | parent | totalsize | freesize | usedsize
----------------------------+-------------------------+------------------------------+-------+------------------------------+-----------+----------+----------
0.140169093357952 | postmaster | Postmaster | | TopMemoryContext | | |
0.140169093357952 | postmaster | gs_signal | | TopMemoryContext | | |
1594694378.140168361137920 | WLMCollectWorker | CacheMemoryContext | | TopMemoryContext | | |
1594694378.140168296134400 | WLMarbiter | CacheMemoryContext | | TopMemoryContext | | |
1594694378.140168465999616 | JobScheduler | CacheMemoryContext | | TopMemoryContext | | |
1594708276.140168270964480 | postgres | CacheMemoryContext | | TopMemoryContext | | |
1594694438.140168207001344 | postgres | CacheMemoryContext | | TopMemoryContext | | |
1594694378.140168344356608 | WLMmonitor | CacheMemoryContext | | TopMemoryContext | | |
1594708276.140168270964480 | postgres | TempSmallContextGroup | | | | |
1594694438.140168207001344 | postgres | TempSmallContextGroup | | | | |
1594708276.140168270964480 | postgres | SRF multi-call context | | FunctionScan_140168270964480 | | |

3. PG_SHARED_MEMORY_DETAIL视图

华为云数仓GaussDB(DWS)除了通用内存上下文以外,还包含共享内存上下文类型用于线程间共享数据。由于共享内存上下文是属于一个进程的,故该视图相比PV_SESSION_MEMORY_DETAIL,不存在sessid,其他的字段含义相同。

postgres=# select * from PG_SHARED_MEMORY_DETAIL order by totalsize desc;
contextname | level | parent | totalsize | freesize | usedsize
----------------------------------------+-------+----------------------------------------+-----------+----------+----------
Workload manager memory context | | ProcessMemory | | |
PoolerAgentContext | | PoolerMemoryContext | | |
PoolerCoreContext | | PoolerMemoryContext | | |
ProcessMemory | | | | |
wlm iostat info hash table | | Workload manager memory context | | |
WaitCountGlobalContext | | ProcessMemory | | |
wlm user info hash table | | Workload manager memory context | | |
OBS connector cache | | ProcessMemory | | |
Resource pool hash table | | Workload manager memory context | | |
Dummy server cache | | ProcessMemory | | |
Node Pool | | PoolerCoreContext | | |

内存相关数据收集

通过前面讲述的几个内存视图,我们可以对华为云数仓GaussDB(DWS)内存有一个整体的理解。下面将分享几个内存相关数据收集的功能。

注意: 鉴于论坛中的问题多是release版本,故debug版本的各种内存相关功能将不再此次介绍以免混淆。同时收集数据就会带来一些消耗,避免长期大规模的使用下面的方案,仅用作问题诊断数据分析使用。

1. pv_session_memctx_detail函数

通过上面的视图介绍我们了解到了PV_SESSION_MEMORY_DETAIL视图的作用。我们可以通过pv_session_memctx_detail打印出该线程内存上下文的详细信息。注意第一个参数表示线程ID,我们根据上线的介绍得知sessid的后半部分就是线程ID。第二个参数表示需要打印内存上下文的名称,在release为空才可以生效即由TopMemoryContext开始递归打印内存上下文信息。Release版本不包含chunk的详细信息。

例如:

select * from pv_session_memctx_detail(,'');

生成的文件默认在/tmp/dumpmem下,文件中三列分别表示内存上下文名称,总大小,剩余大小。

文件内容样例:

140168207001344_1594695418.log

TopMemoryContext, ,
Record information cache, ,
TableSpace cache, ,
set params hash table, ,
VecFuncHash, ,
MaskPasswordCtx, ,
RowDescriptionContext, ,
MessageContext, ,
Operator class cache, ,
smgr relation table, ,

2. memory_tracking_mode参数

除了上面的内存上下文数据统计,我们还可以通过memory_tracking_mode设置内存信息统计的模式,共支持四种模式:

none:不启动内存统计功能。

normal:仅做内存实时统计,不生成文件。

executor:生成统计文件,包含执行层使用过的所有已分配内存的上下文信息。当为executor模式时,将在GaussDB进程(取决于在哪个数据节点最终执行了该算子)的pg_log目录下生成cvs格式文件,命名方式为:memory_track_<DN名称>_query_<queryid>.csv。作业执行时,执行器postgres线程和所有stream线程执行的算子信息,都将输入该文件。其中各字段分别为:输出顺序号、线程内分配内存上下文的顺序号、当前内存上下文的名称、父内存上下文的输出顺序号、父内存上下文的名称、内存上下文树形层次级别号、当前内存上下文使用的内存峰值、当前内存上下文及其所有子内存上下文使用的内存峰值、当前线程所在query的plannodeid。

fullexec:生成文件包含执行层申请过的所有内存上下文信息。当设置为fullexec模式时,输出信息和executor模式相同,但可能增加部分内存上

下文分配信息,因为所有申请内存(无论是否申请成功)相关的信息都会被打印出来。由于仅记录内存申请信息,故记录中内存上下文使用的峰值均为0。

csv文件内容样例:

memory_track_datanode1_query_72339069014639220.csv

, , ExecutorState, , (null), , 8K, 656K,
, , CStoreScan_139944754403072, , ExecutorState, , 272K, 625K,
, , cstore scan per scan memory context, , CStoreScan_139944754403072, , 24K, 24K,
, , cstore scan memory context, , CStoreScan_139944754403072, , 328K, 328K,
, , VecToRow_139944754403072, , ExecutorState, , 23K, 23K,
, , ExecutorState, , (null), , 8K, 144K,
, , Stream_72339069014639220_4, , ExecutorState, , 72K, 72K,
, , Sort_72339069014639220_3, , ExecutorState, , 8K, 40K,
, , TupleSort, , Sort_72339069014639220_3, , 32K, 32K,
, , Agg_72339069014639220_2, , ExecutorState, , 24K, 24K,

一些诊断方案:

1. 内存膨胀

在release版本调试工具以及信息比较受限,基本都是先通过前面介绍的三种视图初步定位大致功能。首先查看PV_TOTAL_MEMORY_DETAIL视图确定是哪一块内存出现了膨胀或者泄露。若是other_used_memory则要考虑三方仓的场景。若是dynamic_used_memory较大,则要查PV_SESSION_MEMORY_DETAIL视图,查看哪个线程,哪个内存上下文占用内存过多。根据这些信息推断出大致问题场景。

2. 内存不足

在内核发现内存不足的时候会有memory is temporarily unavailable的日志提示。首先观察日志,若日志里是reaching the database memory limitation则说明内核使用内存到达了max_dynamic_memory,则需要根据PV_SESSION_MEMORY_DETAIL视图分析是那个内存上下文占用内存较多,分析出业务场景。若日志里是reaching the OS memory limitation,则表示是操作系统分配内存失败导致,需要看操作系统参数配置以及内存硬件等情况。

小结:

生产环境出现内存问题一般会比较棘手,而且release版本内存检测工具以及数据信息使用都比较受限,遇到问题需要通过上述的方案以及手段快速定位出出现内存问题的相关业务场景。有了业务场景,后面通过debug版本使用ASAN地址消毒技术以及Jemalloc Profiling便可以较快的定位出来。

点击关注,第一时间了解华为云新鲜技术~

最新文章

  1. tyvj1008 传球游戏
  2. C++多线程の8*2重多线程创建方式
  3. 锋利的JQuery —— Ajax
  4. 为 mysql 数据表添加主键
  5. 如何在URL筛选管理器中过滤不需要的URL
  6. Caused by: javax.xml.bind.JAXBException: standardPremiumUpdateMessageDTO is not a valid property on
  7. FZU 2171(线段树的延迟标记)
  8. WS之cxf的权限拦截器应用
  9. gulp.watch监听文件
  10. Sublime Text3 个人使用心得
  11. JavaScript函数柯里化的一些思考
  12. sqlplus登录问题
  13. cnn 文章
  14. mysql7笔记----存储过程实例
  15. Python: tree data structure
  16. [cb]SceneView 获取鼠标位置
  17. cnblogs博客申请完毕,以后再这里安家落户
  18. 跟bWAPP学WEB安全(PHP代码)--SSL(Server-Side-Include)漏洞
  19. 小程序getUserInfo授权升级更新登录优化
  20. python函数修饰器(decorator)

热门文章

  1. Java 项目创建 -- 统一结果处理、统一异常处理、统一日志处理
  2. kafka的认识、安装与配置
  3. CVE-2020-5902 简单复现
  4. Win10 环境变量
  5. pip install scrapy报错:error: Unable to find vcvarsall.bat解决方法
  6. python 爬虫写入txt:UnicodeEncodeError: ‘gbk’ codec can’t encode character 错误的解决办法
  7. 机器学习实战基础(二十九):决策树(二)DecisionTreeClassifier与红酒数据集
  8. Python Ethical Hacking - BACKDOORS(3)
  9. MVC + EFCore 项目实战 - 数仓管理系统6 – 数据源管理上--使用view component完成卡片列表
  10. Saas Erp以及分销 助手