在postgresl 9.0上我们有一个SQL查询:
SELECT count(*) FROM lane WHERE not exists (SELECT 1 FROM id_map WHERE id_map.new_id=lane.lane_id and id_map.column_name='lane_id' and id_map.table_name='lane') and lane.lane_id is not null;
这通常需要大约1.5秒才能完成.
这是解释计划:http://explain.depesz.com/s/axNN
有时虽然此查询挂起但无法完成.它甚至可以运行11个小时但没有成功.
然后它占用了100%的cpu.
此查询所采用的唯一锁定是“AccessShareLock”,它们都被授予.
SELECT a.datname,c.relname,l.transactionid,l.mode,l.granted,a.usename,a.current_query,a.query_start,age(Now(),a.query_start) AS "age",a.procpid FROM pg_stat_activity a JOIN pg_locks l ON l.pid = a.procpid JOIN pg_class c ON c.oid = l.relation ORDER BY a.query_start;
该查询作为使用连接池连接到数据库的java进程的一部分运行,并执行此格式的顺序类似的选择查询:
SELECT count(*) FROM {} WHERE not exists (SELECT 1 FROM id_map WHERE id_map.new_id={}.{} and id_map.column_name='{}' and id_map.table_name='{}') and {}.{} is not null
没有更新或删除与此过程并行发生,所以我不认为吸尘可能是这里的问题.
在运行整个过程之前(因此在运行此类6个查询之前),运行了对所有表的分析.
postgres日志不显示长时间运行的查询的任何条目,因为它们永远不会完成,因此永远不会被记录.
知道什么可能导致这种行为以及如何防止它发生?
没有分析的解释计划:
Aggregate (cost=874337.91..874337.92 rows=1 width=0) -> nested Loop Anti Join (cost=0.00..870424.70 rows=1565283 width=0) Join Filter: (id_map.new_id = lane.lane_id) -> Seq Scan on lane (cost=0.00..30281.84 rows=1565284 width=8) Filter: (lane_id IS NOT NULL) -> Materialize (cost=0.00..816663.60 rows=1 width=8) -> Seq Scan on id_map (cost=0.00..816663.60 rows=1 width=8) Filter: (((column_name)::text = 'lane_id'::text) AND ((table_name)::text = 'lane'::text))
解决方法
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。