一、问题现象：

客户环境dws版本8.1.3
1、用户执行sql语句时产生一个WARNING：TopSQL lfq is full, failed to save queryid: XXXXXXXXX。
2、查询topsql表pgxc_wlm_session_info慢的问题，TopSQL转储到hadoop长时间卡住的问题。

问题分析：

1、topsql的信息是由cn上workload线程收集各个dn上报的数据并进行汇总，因此通过等待视图pg_thread_wait_status查看workload线程的query_id，再通过等待视图pgxc_thread_wait_status查看query_id的等待情况。

2、workload线程分别在cn上等待dn_6973_6974，而dn_6973_6974上也在等待读取数据。使用gstack在cn、dn上打印堆栈进一步确认情况，cn堆栈信息如下（dn堆栈略）：

3、通过等待视图和堆栈信息分析发现workload线程阻塞在copy过程中，进一步排查日志中copy的状态转换流程发现，正常的copy流程为INITIALIZING->INITIALIZING  to TRANSFER_DATA->TRANSFER_DATA to RELEASE_RESOURCE。而topsql的copy的状态转换流程不完整，缺少RELEASE_RESOURCE状态。

通过进一步分析堆栈信息，判断在dn6973进行copy流程时，异常结束或hang住未退出。

4、1）与此同时，还发现TopSQL表等锁的现象：

2）该锁信息查找到对应的SQL语句为TopSQL的表在新增分区的操作：

alter table dbms_om.gs_wlm_session_info split partition at(xxx) into (partition xxx);

3）而持锁的sql为客户topsql转储至hadoop的业务sql：简化如下

select * from dbms_om.gs_wlm_session_info where finish_time>'xxx'

二、问题根因

1、记录TopSQL的原理：

8.1.3记录TopSQL由之前8.0在CN上存储转化为在DN上存储，并且DN上的表由普通表转化为按天保存数据的分区表：

图 10 8.0与8.1.3 TopSQL存储方式的对比

       变化一：由CN内转储转化为CN到DN间转储，CN的数据量大大降低，后续扩容，修复CN的时间消耗大为减少

       变化二：由普通表转化为分区表，分区键是”start_time”,按天划分分区，对于数据查询，数据老化等操作更轻量级。

       变化三：TopSQL的分区表会创建提前三天的，例如当前是7月24号会创建7月27号的分区，只访问当天的数据不会与新建分区冲突。

2、出现WARNING：TopSQL lfq is full的原因：

       问题出现在CN向DN转储的过程中，CN向DN转储使用类似copy语句的方式，由CN分批将数据发送给DN的物理表中，在此过程中DN每收到一批数据，就会向CN发送应答的消息。由于某种原因（CN再给DN发送结束报文（EOF）时出错后处理逻辑出现CN认为发送成功而DN在等待CN发送结束指令，CN和DN都在等待对方的应答，导致整个转储过程夯住，CN内存中数据无法转储， CN上TopSQL缓存（1GB）满之后新的TopSQL信息就无法写入，产生Warning级别的错误日志： “WARNING：TopSQL lfq is full…”，流程见下图：

图 11 TopSQL转储的问题示意图

3、TopSQL转储为何会影响转储到HDFS上，并出现等锁的情况

8.1.3将TopSQL转为普通的分区表后，每天都会通过如下语句

“ALTER TABLE dbms_om.gs_wlm_session_info SPLIT PARTITION p_max TO …”新建当天的分区，该语句会在表dbms_om.gs_wlm_session_info上加“读锁”（只与访问排它锁互斥，其它类型锁都不相关），而在max_value的分区上添加“访问排它锁”（最高级别锁，阻止其它会话的读写操作）。

梳理发生问题的时间线：

1）等锁场景一：CN 向DN转储时夯住（此时会对表加3级锁）->TopSQL自动增分区的操作被阻塞（分区申请”访问排它锁”，与“行级排它锁”锁冲突，等待）-> TopSQL导出到HDFS （申请“行级排它锁”）同样等待

2）等锁场景二：TopSQL自增分区（表上“读锁”，分区申请“访问排它锁”）与TopSQL转储到HDFS中如果涉及所有分区就会锁等待

4、查询select * from pgxc_wlm_session_info耗时长的问题

耗时长的问题是由于其查询时遇到增加分区或者交换分区的操作导致，同时原查询使用finish_time做过滤条件。建议查询时使用start_time作为条件，只查询今天和今天之前的数据，避免全表扫描。

三、解决方案

1. 改由pgxc_wlm_session_info代替从每个CN上执行gs_wlm_session_info抽取
2. 客户转储sql添加分区键start_time保证可以进行分区剪枝只处理已有分区，避免与新增分区的锁冲突，此时不会在老分区上加锁，因此不影响转储的执行

四、总结

通过本案例学习，可以收获到

1、学习到dws的topsql内部转储的原理。不同版本，产品设计存在差异，需要与时俱进，更新知识储备。

2、部分hang问题的处理思路，可以通过对pgxc_stat_activity、pgxc_thread_wait_status视图，gstack打堆栈排查根因。

     通过分区剪枝能大大提升sql性能，部分场景可以减少锁冲突。