梧桐数据库2.0版本不再沿用传统的进程模型，采用了线程模型并提供了一系列的系统视图方便追踪和调试慢SQL。本文对常用的几个监控视图进行简单介绍，并对常用的视图给出示例SQL。

1. pg_stat_activity视图

pg_stat_activity是继承于PG的一个内置系统视图，用于显示当前正在进行的数据库会话（连接）的活动信息。通过查询这个视图，数据库管理员可以监控当前数据库的状态，识别性能瓶颈，解决锁争用问题，确保系统正常运行。
主要字段和含义如下：

• datname：数据库会话对应的数据库。
• pid：数据库会话对应的线程号。
• usename：数据库会话对应的用户名。
• wait_event_type：当前等待事件的类型。
• wait_event：当前等待的具体事件。
• state：当前会话的状态（如 active, idle, idle in transaction, etc.）。
  通过wait_event_type和wait_event可以初步排查慢SQL，并确认是存在锁竞争或其他等待事件，示例：

SELECT CURRENT_TIMESTAMP - query_start AS query_time
    ,pid
    ,usename
    ,wait_event_type
    ,wait_event
    ,query
    ,state
FROM pg_stat_activity WHERE state<>'idle' ORDER BY query_time DESC;

-- session1(pid 1298)在事务中先执行了drop table操作，此时正在等待客户端输入，具体等待事件为ClientRead。
-- session2(pid 1840)执行查询，由于t1表被drop操作锁住，当前SQL存在锁竞争，具体等待事件为DLM（锁管理模块）。
-- Client：服务器进程正在一个套接字上等待来自用户应用的某种活动，并且该服务器预期某种与其内部处理无关的事情发生。wait_event将标识特定的等待点。
-- IPC：服务器进程正在等待来自服务器中另一个进程的某种活动。wait_event将标识特定的等待点。
   query_time    | pid  | usename | wait_event_type | wait_event |                               query                                |        state        
-----------------+------+---------+-----------------+------------+--------------------------------------------------------------------+---------------------
 00:01:50.409223 | 1298 | u1      | Client          | ClientRead | drop table t1;                                                      | idle in transaction
 00:01:26.521291 | 1840 | u1      | IPC             | DLM        | select count(*) from t1;                                            | active
...

-- 添加pg_sleep来模拟执行耗时长的SQL，wait_event为Interconnect时，说明此时master正在等待通信模块返回数据。
-- 如果SQL长时间未执行完，需要结合Gang信息进一步分析。
   query_time    | pid  | usename | wait_event_type |  wait_event  |                                query                                | state  
-----------------+------+---------+-----------------+--------------+---------------------------------------------------------------------+--------
 00:00:44.188958 | 1298 | sjw     | IPC             | Interconnect | select count(*) from (select pg_sleep(1) from t1) s1;               | active
...

2. segment_status_detail函数

segment_status_detail函数可以查看Gang中所有线程的信息，通过pg_stat_activity中的sess_id进行关联。一般都在耗时较长的操作前都会设置wait_event_type和wait_event，需要结合实际情况进行分析。

SELECT
    host
    ,sess_id
    ,command
    ,slice
    ,vsegno
    ,wait_event_type
    ,wait_event
    FROM wutong_toolkit.segment_status_detail() 
    segment_status_detail(host, pid, sess_id, command, slice, vsegno, database_id, state, wait_event, wait_event_type, cpu_usage)
    WHERE sess_id=$1 AND command<>0 
    ORDER BY host,command,slice,vsegno;
-- 4条记录说明slice1在host 172.17.0.2上有四个vseg正在运行。
-- wait_event_type说明在等待超时，具体的事件则是PgSleep函数。
    host    | sess_id | command | slice | vsegno | wait_event_type | wait_event 
------------+---------+---------+-------+--------+-----------------+------------
 172.17.0.2 | 1048606 |       2 |     1 |      0 | Timeout         | PgSleep
 172.17.0.2 | 1048606 |       2 |     1 |      0 | Timeout         | PgSleep
 172.17.0.2 | 1048606 |       2 |     1 |      0 | Timeout         | PgSleep
 172.17.0.2 | 1048606 |       2 |     1 |      0 | Timeout         | PgSleep
(4 rows)

3. segment_memory_summary函数

当SQL涉及的基表数据量较大或运算较为复杂时，一些内存密集型算子会出现数据落盘或者内存超出限制报错的情况。如果需要分析内存占用是否合理，可以通过segment_memory_summary函数对SQL的内存上下文进行分析。树形结构的内存上下文能在频繁的内存分配和回收有效的避免内存泄漏，而且通过pg本身维护的一块内存池，能不通过操作系统取得适配内存，在一定程度上提高效率。上下文有进程共享的共享内存上下文，也有每个session独立的内存上下文（TopMemoryContext）以及语句级别和算子级别的内存上下文，语句级别和算子级别的上下文会随着执行的结束自动销毁释放。可以通过下面的SQL查询内存使用量TOP 10的内存上下文。

SELECT host, pid, sess_id, slice, vsegno, context, sum(allocated)/1024/1024 as allocatedMB,
       sum(total)/1024/1024 as totalMB,
       count(*)
FROM wutong_toolkit.segment_memory_summary() segment_memory_summary(host, pid, sess_id, command, slice, vsegno, context, parent, level, peak, allocated, total)
GROUP BY host, pid, sess_id, slice, vsegno, context
ORDER BY allocatedMB desc
LIMIT 10;

下面以一个简单SQL为例进行说明，观测计划中HashJoin算子内存消耗情况。

select count(*) from (select * from t1 tt1, t1 tt2 where tt1.a=tt2.a) s1;
                                        QUERY PLAN                                         
-------------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=0.00..966.88 rows=1 width=8)
   ->  Gather Motion 4:1  (slice1; segments: 4)  (cost=0.00..966.88 rows=1 width=8)
         ->  Partial Aggregate  (cost=0.00..966.88 rows=1 width=8)
               ->  Hash Join  (cost=0.00..966.88 rows=249897 width=1)
                     Hash Cond: (tt1.a = tt2.a)
                     ->  Seq Scan on t1 tt1  (cost=0.00..435.39 rows=249353 width=4)
                     ->  Hash  (cost=435.39..435.39 rows=249353 width=4)
                           ->  Seq Scan on t1 tt2  (cost=0.00..435.39 rows=249353 width=4)
 Optimizer: GPORC
(9 rows)

    host    | pid  | sess_id | slice | vsegno |     context      |     allocatedmb      |       totalmb        | count 
------------+------+---------+-------+--------+------------------+----------------------+----------------------+-------
-- 1048581是查询语句的session id，可以看到HashBatchContext申请了105.84M内存，实际使用了105.62M的内存
-- TopMemoryContext是session级别的内存上下文，一般情况下可以忽略
 172.17.0.2 | 1367 | 1048581 |     1 |      0 | HashBatchContext | 105.6264953613281250 | 105.8484802246093750 |     4
 172.17.0.2 | 1367 | 1048581 |     1 |      0 | TopMemoryContext |   4.0381469726562500 |   4.2219238281250000 |     4
...

总结

系统视图和系统函数提供了初步的排查、定位手段，但是一些复杂问题还是需要借助更多的工具来进行分析。

产品简介

• 梧桐数据库（WuTongDB）是基于 Apache HAWQ 打造的一款分布式 OLAP 数据库。产品通过存算分离架构提供高可用、高可靠、高扩展能力，实现了向量化计算引擎提供极速数据分析能力，通过多异构存储关联查询实现湖仓融合能力，可以帮助企业用户轻松构建核心数仓和湖仓一体数据平台。
• 2023年6月，梧桐数据库（WuTongDB）产品通过信通院可信数据库分布式分析型数据库基础能力测评，在基础能力、运维能力、兼容性、安全性、高可用、高扩展方面获得认可。
  点击访问：
  梧桐数据库（WuTongDB）相关文章
  梧桐数据库（WuTongDB）产品宣传材料
  梧桐数据库（WuTongDB）百科