共计 7360 个字符,预计需要花费 19 分钟才能阅读完成。
前言
在日常数据库的应用中,难免会遇到一些内存问题。此次博文次要向大家分享一些华为云数仓 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 | 12288
coordinator1 | process_used_memory | 240
coordinator1 | max_dynamic_memory | 11564
coordinator1 | dynamic_used_memory | 229
coordinator1 | dynamic_peak_memory | 234
coordinator1 | dynamic_used_shrctx | 1
coordinator1 | dynamic_peak_shrctx | 1
coordinator1 | max_shared_memory | 211
coordinator1 | shared_used_memory | 139
coordinator1 | max_cstore_memory | 512
coordinator1 | cstore_used_memory | 0
coordinator1 | max_sctpcomm_memory | 0
coordinator1 | sctpcomm_used_memory | 0
coordinator1 | sctpcomm_peak_memory | 0
coordinator1 | other_used_memory | 0
coordinator1 | gpu_max_dynamic_memory | 0
coordinator1 | gpu_dynamic_used_memory | 0
coordinator1 | gpu_dynamic_peak_memory | 0
coordinator1 | pooler_conn_memory | 0
coordinator1 | pooler_freeconn_memory | 0
coordinator1 | storage_compress_memory | 0
coordinator1 | udf_reserved_memory | 0
(22 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 | 1 | TopMemoryContext | 26566912 | 23912 | 26543000
0.140169093357952 | postmaster | gs_signal | 1 | TopMemoryContext | 4272464 | 2050224 | 2222240
1594694378.140168361137920 | WLMCollectWorker | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 268488 | 1186544
1594694378.140168296134400 | WLMarbiter | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 266696 | 1188336
1594694378.140168465999616 | JobScheduler | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 239584 | 1215448
1594708276.140168270964480 | postgres | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 316392 | 1138640
1594694438.140168207001344 | postgres | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 329944 | 1125088
1594694378.140168344356608 | WLMmonitor | CacheMemoryContext | 1 | TopMemoryContext | 1455032 | 269528 | 1185504
1594708276.140168270964480 | postgres | TempSmallContextGroup | 0 | | 550592 | 160320 | 114
1594694438.140168207001344 | postgres | TempSmallContextGroup | 0 | | 530816 | 148256 | 107
1594708276.140168270964480 | postgres | SRF multi-call context | 5 | FunctionScan_140168270964480 | 496704 | 8032 | 488672
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 | 1 | ProcessMemory | 1056832 | 6080 | 1050752
PoolerAgentContext | 2 | PoolerMemoryContext | 57344 | 36000 | 21344
PoolerCoreContext | 2 | PoolerMemoryContext | 57344 | 30544 | 26800
ProcessMemory | 0 | | 57344 | 28304 | 29040
wlm iostat info hash table | 2 | Workload manager memory context | 24576 | 10832 | 13744
WaitCountGlobalContext | 1 | ProcessMemory | 24576 | 9984 | 14592
wlm user info hash table | 2 | Workload manager memory context | 24576 | 10832 | 13744
OBS connector cache | 1 | ProcessMemory | 24576 | 15056 | 9520
Resource pool hash table | 2 | Workload manager memory context | 17984 | 2704 | 15280
Dummy server cache | 1 | ProcessMemory | 8192 | 2832 | 5360
Node Pool | 3 | PoolerCoreContext | 8192 | 768 | 7424
内存相干数据收集
通过后面讲述的几个内存视图,咱们能够对华为云数仓 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(140168207001344,'');
生成的文件默认在 /tmp/dumpmem 下,文件中三列别离示意内存上下文名称,总大小,残余大小。
文件内容样例:
140168207001344_1594695418.log
TopMemoryContext, 460808, 24728
Record information cache, 24576, 14928
TableSpace cache, 8192, 2304
set params hash table, 8192, 2832
VecFuncHash, 122272, 20928
MaskPasswordCtx, 8192, 8144
RowDescriptionContext, 8192, 7104
MessageContext, 8192, 7104
Operator class cache, 8192, 768
smgr relation table, 24576, 8880
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
0, 0, ExecutorState, 0, (null), 0, 8K, 656K, 4
1, 4, CStoreScan_139944754403072, 0, ExecutorState, 1, 272K, 625K, 4
2, 9, cstore scan per scan memory context, 1, CStoreScan_139944754403072, 2, 24K, 24K, 4
3, 8, cstore scan memory context, 1, CStoreScan_139944754403072, 2, 328K, 328K, 4
4, 2, VecToRow_139944754403072, 0, ExecutorState, 1, 23K, 23K, 4
0, 0, ExecutorState, 0, (null), 0, 8K, 144K, 0
1, 13, Stream_72339069014639220_4, 0, ExecutorState, 1, 72K, 72K, 0
2, 10, Sort_72339069014639220_3, 0, ExecutorState, 1, 8K, 40K, 0
3, 16, TupleSort, 2, Sort_72339069014639220_3, 2, 32K, 32K, 0
4, 2, Agg_72339069014639220_2, 0, ExecutorState, 1, 24K, 24K, 0
一些诊断计划:
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 便能够较快的定位进去。
点击关注,第一工夫理解华为云陈腐技术~