PostgreSQL长事务引发的问题
我是本际云服务器推荐网的小编小本本,最近接到一个故障处理的任务,PostgreSQL某系统数据库反馈数据库慢,经过使用Pgbadger分析慢日志发现某SQL执行消耗较高,平均2S执行时间。分析索引表上的列msg_source存在索引,该表可以正常走索引,但是查询速度一直非常慢,进一步分析表发现有273852002行死元组未被清理,影响查询速度。

解决方案
为解决该问题,我们分析了二个方面,分别是表的死元组和长事务。
第一,针对死元组问题,我们查看表上last_autovacuum已做但是没有生效,手动vacuum也没有生效,因为存在长事务影响vacuum回收。所以,我们人工杀死长事务后,再次执行vacuum表,执行成功。通过与回收前和回收后的执行计划对比,优化前需要3.9S的时间,而优化后只需要4ms,成功优化了表的查询效率。
第二,长事务引发的问题。我们发现长事务是11月17日连接上来的,至今已经三天,但是并没有被postgre系统进程杀死。因此,我们手动将长事务杀死后,问题得到了解决。但是,又产生了一个新的疑惑,数据库设置了idle_in_transaction_session_timeout参数为20S,为什么没有杀死长事务会话。我们进行了多次测试,发现其他idleintransaction会话都会被系统杀死,但是这个长事务会话无法复现这个问题,成为了一道悬案,后面再进行研究。
以上就是我们针对PostgreSQL长事务引发的问题进行的解决方案,通过正确的分析与优化,成功解决了表的死元组问题,同时也对长事务引发的问题进行了解决。
原创文章,作者:小编小本本,如若转载,请注明出处:https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/6197.html
