一、问题现象

在gsql中执行以下sql，发现部分insert语句执行2分钟。

execute direct on all $$ select query_start, now()-query_start,xact_start,application_name,waiting,query from pg_stat_activity order by 1 asc limit 3 $$;

但是通过以下sql查询各节点，发现没有等锁的情况。

execute direct on all $$ select d.datname as datanme, n.nspname as nspname, c.relname as relname, c.reltype as reltype, g.* from dbe_perf.global_locks as g , pg_class as c , pg_database as d, pg_namespace as n where c.oid=g.relation and g.database=d.oid and c.relnamespace=n.oid and g.granted='f' $$;

二、问题分析

通过pid或session_id,在pg_thread_wait_status表中查找cn在等dn1节点，通过pstack能看到cn的lightPorxy正在等dn返回结果。

在dn1中从pg_stat_activity中获取执行耗时长sql的会话信息，然后通过pg_thread_wait_status获得对应的线程信息，再通过pstack观察线程的主要堆栈。发现频繁进入audit流程，怀疑审计内容过多，导致sql变慢。

将所有节点的audit_enabled置为off后，insert性能恢复正常，问题得到解决。