openGauss的ASH

openGauss的ASP是和WDR一体化设计的功能，这一点十分重要，因为ASP和WDR是相辅相成，互相补充的。和Oracle 的ASH不同的是，openGauss的ASP支持3种持久化方式，默认的方式是类似Oracle的数据表保存模式，将数据定期持久化到GS_ASP表中；第二种方式是文件方式，直接将内存中的ASP数据输出到磁盘文件中，输出到磁盘文件有助于提升ASP输出的效率，也方便监控软件更为低成本的采集ASP数据；第三种方式是表+文件的方式，实际上这种方式的使用场景会十分有限，因为无论如何，在一个高并发的系统中，输出ASP数据都是有成本的。输出到文件是ASP中的一个不错的设计，不过似乎对于ASP文件的保存期限openGauss并没有做自动管理。比如根据asp_retention_days参数做自动的清理操作（默认保存2天）。随着时间推移，如果DBA忘记了清理数据，会导致PGDATA目录被大量占用，影响系统的稳定运行。

我尝试了将asp_flush_mode设置为file,不过似乎并没有直接起效，不过在PGDATA下有一个asp_data的目录，每天0点会自动产生一个ASP文件，无论参数设置为TABLE还是FILE。这个功能以后我们再来尝试一下。

ASP功能通过asp_sample_interval参数来定义系统采样活跃会话的频率，默认是1秒钟，如果对监控要求没那么高，或者系统负载过高，可以考虑加大这个参数设置。

asp_sample_num参数控制了在内存中保存的ASP采样刷盘数量，达到这个数量ASP数据会被刷盘，默认是10万条，如果我们的业务高峰时期，活跃会话数量是500，那么10万条可以保存200秒的数据，也就是3分多钟，对于较为大型的系统来说，如果物理内存足够大，可以设置更大的值。不过如果一次性过多的数据被同时刷盘，那么过大的设置会引发瞬间的高负载，这一点一定要注意。

参数asp_flush_rate是限制ASP数据刷入持久化存储的比例的参数，默认是10，也就是说默认只有1/10的活跃会话数据会被采样存储到持久化存储中，其他的数据一旦缓冲区写满就会被丢弃。如果你想要加大持久化的采样比例，可以调小该参数，调整为1就是1：1写盘。openGauss的gs_asp表被创建为普通表，而没有被创建成一个unlogged table，因此大量写入ASP数据的开销还是有点大。实际上，gs_asp表示不怕数据损坏的，因此完全可以创建为unlogged table，从而降低写入ASP数据的开销，提升写入性能。

从数据上看，ASP的数据已经包含了ASH分析所需要的基本信息，唯一让Oracle dba感到有些遗憾的是，等待事件的等待时间并没有包含，当然openGauss也提供了某个等待事件的等待次数和时长的统计数据供参考。

可能是从性能的考虑吧，这张表上只有一个sample_time的索引，不过大多数ASP分析也都是基于时间区间的，对于大多数分析操作来说也够用了。

openGauss的ASP在内存中也是可以访问的，不过要通过另外的接口，高斯数据库访问内存的性能数据一般都通过dbe_perf下的视图local_active_session。

openGauss并没有像Oracle一样提供一个统一的视图来获取内存和表中的数据，提供了两个接口。如果我们在分析ASP的时候需要获得完整的数据，需要通过一个UNION操作来访问这两个接口。

另外openGauss也提供了一个get_local_active_session的函数来获取内存中的ASP数据，不过这个函数功能上面还不够完善，只能一次性取出所有的ASP内存中的数据，如果能够加上一些根据sample_time或者SESSION ID的筛选条件就更完美了。

高斯的ASP采集功能是通过enable_asp参数来控制的，默认情况下，这个参数是on，ASP采集是开启的。这说明高斯的厂商认为ASP的功能是成熟的，打开ASP采集并不会过大的影响高斯的性能。这一点是十分重要的。