postgresql seq扫描有时很慢。 postgres的重启解决了一段时间

时间:2016-07-07 09:11:05

标签: postgresql postgresql-performance

我遇到一个问题,即表上的相同查询有时需要几秒钟,大多数时间在几毫秒内完成。 Postgres的重新启动似乎解决了这个问题并将其保留了几天。

  • 表格 - 闹钟
  • 从表中读到的20位客户。
  • 1个客户端每秒进行几次插入和udpate。删除/清除是一个夜间的cron。
  • 仍有大量RAM可用,主机上只有20%的CPU使用。

在上述条件持续一段时间后,查询开始需要5秒以上才能完成。

只需重新启动客户端,Postgres通过将其降低到几毫秒来解决这个问题。

explain analyze显示此表的顺序扫描时间。但是,当Postgres刚刚启动时,它大约为毫秒级,之后会增加到几秒钟。

此表中有大约25000条记录。

有关seq扫描速度慢时如何调试的任何建议和想法?它可能是shared_buffer中的碎片或导致这种情况的表的锁定。我怀疑这是一个磁盘或IO问题,因为无论Postgres何时启动它们都会引起问题。

在发布问题时,我错过了在分析中使用缓冲区。输出如下:


    explain analyze SELECT s.severity, s.severityid from SEVERITY s where s.severityid =(select MIN(severityid) from  ALARM a, (SELECT * FROM RESOURCEDETAILS) as  RESOURCEDETAILS  WHERE RESOURCEDETAILS.resourcegroupid = 132 AND RESOURCEDETAILS.resourceid = a.resourceid AND a.severityid  1 AND a.severityid  2 AND a.severityid  7);
                                                                             QUERY PLAN
    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    Seq Scan on severity s  (cost=4701.39..4702.47 rows=1 width=13) (actual time=7057.939..7057.940 rows=1 loops=1)
       Filter: (severityid = $0)
       Rows Removed by Filter: 6
       InitPlan 1 (returns $0)
         ->  Aggregate  (cost=4701.38..4701.39 rows=1 width=8) (actual time=7057.918..7057.918 rows=1 loops=1)
               ->  Hash Join  (cost=533.69..4701.25 rows=51 width=8) (actual time=1849.630..7057.783 rows=223 loops=1)
                     Hash Cond: (a.resourceid = resourcedetails.resourceid)
                     ->  Seq Scan on alarm a  (cost=0.00..4157.70 rows=2491 width=16) (actual time=45.792..6608.120 rows=852 loops=1)
                           Filter: ((severityid  1) AND (severityid  2) AND (severityid  7))
                           Rows Removed by Filter: 24376
                     ->  Hash  (cost=528.27..528.27 rows=434 width=8) (actual time=448.540..448.540 rows=19 loops=1)
                           Buckets: 1024  Batches: 1  Memory Usage: 1kB
                           ->  Bitmap Heap Scan on resourcedetails  (cost=7.65..528.27 rows=434 width=8) (actual time=0.128..448.495 rows=19 loops=1)
                                 Recheck Cond: (resourcegroupid = 132)
                                 ->  Bitmap Index Scan on resourcedetails_rg_idx  (cost=0.00..7.54 rows=434 width=0) (actual time=0.103..0.103 rows=63 loops=1)
                                       Index Cond: (resourcegroupid = 132)
    Total runtime: 7058.156 ms
    (17 rows)

After postgres restart, the problem was resolved and here is the output:
(This time with all options of explain)
                                                                             <pre>
explain (analyze,buffers,costs,timing,verbose) SELECT s.severity, s.severityid from SEVERITY s where s.severityid =(select MIN(severityid) from  ALARM a, (SELECT * FROM RESOURCEDETAILS) as  RESOURCEDETAILS  WHERE RESOURCEDETAILS.resourcegroupid = 132 AND RESOURCEDETAILS.resourceid = a.resourceid AND a.severityid <> 1 AND a.severityid <> 2 AND a.severityid <> 7);
                                                                                                                       QUERY PLAN

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------
 Seq Scan on public.severity s  (cost=4516.93..4518.02 rows=1 width=13) (actual time=15.881..15.882 rows=1 loops=1)
   Output: s.severity, s.severityid
   Filter: (s.severityid = $0)
   Rows Removed by Filter: 6
   Buffers: shared hit=3167
   InitPlan 1 (returns $0)
     ->  Aggregate  (cost=4516.92..4516.93 rows=1 width=8) (actual time=15.874..15.875 rows=1 loops=1)
           Output: min(a.severityid)
           Buffers: shared hit=3166
           ->  Hash Join  (cost=520.61..4516.91 rows=5 width=8) (actual time=7.043..15.869 rows=2 loops=1)
                 Output: a.severityid
                 Hash Cond: (a.resourceid = resourcedetails.resourceid)
                 Buffers: shared hit=3166
                 ->  Seq Scan on public.alarm a  (cost=0.00..3995.37 rows=232 width=16) (actual time=0.142..15.492 rows=108 loops=1)
                       Output: a.alarmid, a.eventtypeid, a.severityid, a.source, a.resourceid, a.componentid, a.category, a.createdtime, a.updatedtime, a.owner, a.ackstatus, a.acktime, a.clearedtime, a.messa
ge, a.remedy, a.optionalfield, a.version
                       Filter: ((a.severityid <> 1) AND (a.severityid <> 2) AND (a.severityid <> 7))
                       Rows Removed by Filter: 26130
                       Buffers: shared hit=3108
                 ->  Hash  (cost=515.39..515.39 rows=418 width=8) (actual time=0.338..0.338 rows=19 loops=1)
                       Output: resourcedetails.resourceid
                       Buckets: 1024  Batches: 1  Memory Usage: 1kB
                       Buffers: shared hit=58
                       ->  Bitmap Heap Scan on public.resourcedetails  (cost=7.53..515.39 rows=418 width=8) (actual time=0.033..0.330 rows=19 loops=1)
                             Output: resourcedetails.resourceid
                             Recheck Cond: (resourcedetails.resourcegroupid = 132)
                             Buffers: shared hit=58
                             ->  Bitmap Index Scan on resourcedetails_rg_idx  (cost=0.00..7.42 rows=418 width=0) (actual time=0.023..0.023 rows=61 loops=1)
                                   Index Cond: (resourcedetails.resourcegroupid = 132)
                                   Buffers: shared hit=3
 Total runtime: 15.937 ms
(30 rows)

postgresql重新启动后,查询似乎稳定恶化......

0 个答案:

没有答案