前言
昨晚刷到了两篇性能优化的素材，挺有意思。首先放两张图，各位自行感受一下，em，must be the database！
想必各位 DBA 同仁肯定遇到过类似场景——什么变更都么做，业务突然就变慢了，然后应用人员怒气冲冲地找过来，逮着数据库就一顿喷。毫无疑问，数据库此时一定是第一个被放到砧板上进行鱼肉的。数据库相比其他基础组件，占据着比较核心的位置，向上是各种应用的支撑引擎，向下调动计算、网络、存储等基础资源，和软硬件息息相关，因此成为"背锅侠"在所难免。
怎么解？Trouble shooting 最终式——Blame someone else，甩锅大法。(inherited from Brendan Gregg’s talks on Performance Analysis)
但是，甩也甩不赢的时候怎么办？这个时候，我们便需要一些强有力的工具来自证清白。除了常规的运维工具之外，PostgreSQL 自身也有许多优质的第三方插件，比如 pg_wait_sampling (等待事件)、pg_stat_kcache (资源消耗) 等等。
在 Oracle 中，通过 ASH 实时捕获相关性能数据，为分析在最近时刻的性能问题提供最直接最有效的依据，那么 Oracle 有了，PostgreSQL 也可以有！简单录制一个动图各位看下效果：
ASH Viewer
该工具叫 ASH-Viewer，Zero install，open source。安装过程就不再描述了
Download the latest binary file. Download JDBC driver for your database (Oracle, PostgreSQL) Unpack the binary archive and run ASH-Viewer.jar Open connection dialog and populate them with data (URL for Oracle database: jdbc:oracle:thin:@host:port:SID)
有啥不懂的问问 GPT。让我们看下实际效果：
[postgres@mypg ~]$ pgbench -T 3000 -c 10 -j 1 -p 5432 postgres
starting vacuum...end
...
可以看到，会统计等待事件，不过并没有进行细分
其实每一类大的等待事件还可以细分为很多小的，为此，各位可以搭配 pg_wait_sampling
另外，点到某一时刻，还可以看到该时刻的相关会话
根据对应的 SQL ID 还可以看到相应的 SQL
不过可惜的是，并没有执行计划的展示，倒是已经有人提过相关 issue 了。
因此，我们可以选择搭配 auto_explain/pg_store_plans 等插件，在 14 以后原生支持了 QUERY_ID 的功能， 在 pg_stat_activity、pg_stat_statments 里面会包含一个相同的 query_id，这样对于分析性能问题就要方便多了。不过可惜的是，该工具的 SQL_ID 和原生的 SQLID 并不能对应上，因此执行计划的获取就要稍微费事一点。
另外，ASH Viewer 将数据存储在本地，因此也可以查看历史数据。
小结
ASH Viewer 和 Pigsty 相比，自然是小巫见大巫了。但是麻雀虽小，五脏俱全，并且上手简单，通过实时捕获相关性能数据，为性能分析提供有效依据。另外一款类似插件是 pgsentinel，之前也简单介绍过，各位可以翻翻。
另外昨天整理了一下 PostgreSQL WAL 日志的前世今生与原理，整理文章可以帮助我们系统性地思考与归纳总结，理论与实践相结合是提升自我的不二法门，我会在原理剖析课程中会与各位进行分享，感兴趣的老铁可以瞅瞅，https://www.modb.pro/course/204，录播 + 课件 + 答疑群。
