web-dev-qa-db-ja.com

9.3から9.4へのアップグレード後、PostgreSQLが非常に遅くなる

最近、Amazon RDSインスタンスをPostgreSQL 9.3から9.4にアップグレードしました。アップグレード中に問題は発生しませんでした。その後、実行しましたVACUUM ANALYZE。現在、パフォーマンスは全体的に非常に遅いです。以下は、9.3で1秒未満の時間を費やしたクエリの例です。

EXPLAIN ANALYZE SELECT room_name, id FROM common_activityinstance WHERE started_by_id = 1370408 AND room_name IN ('robcv28', 'foobartest', 'noroster', 'jscode', 'cv28', 'johansencouple', 'lv426', 'johansenfamily', 'johansen') AND end_time IS NULL;
                                                                              QUERY PLAN                                                                              
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on common_activityinstance  (cost=55.63..59.65 rows=1 width=13) (actual time=1.082..1.082 rows=0 loops=1)
   Recheck Cond: ((started_by_id = 1370408) AND (room_name = ANY ('{robcv28,foobartest,noroster,jscode,cv28,johansencouple,lv426,johansenfamily,johansen}'::text[])))
   Filter: (end_time IS NULL)
   Rows Removed by Filter: 925
   ->  BitmapAnd  (cost=55.63..55.63 rows=1 width=0) (actual time=0.349..0.349 rows=0 loops=1)
         ->  Bitmap Index Scan on common_activityinstance_started_by_id  (cost=0.00..5.53 rows=146 width=0) (actual time=0.122..0.122 rows=927 loops=1)
               Index Cond: (started_by_id = 1370408)
         ->  Bitmap Index Scan on common_activityinstance_room_name_c1f9997a_like  (cost=0.00..49.85 rows=1171 width=0) (actual time=0.171..0.171 rows=926 loops=1)
               Index Cond: (room_name = ANY ('{robcv28,foobartest,noroster,jscode,cv28,johansencouple,lv426,johansenfamily,johansen}'::text[]))
 Total runtime: 1.116 ms
(10 rows)

この同じクエリは9.4ではmuch遅くなりました。

EXPLAIN ANALYZE SELECT room_name, id FROM common_activityinstance WHERE started_by_id = 1370408 AND room_name IN ('robcv28', 'foobartest', 'noroster', 'jscode', 'cv28', 'johansencouple', 'lv426', 'johansenfamily', 'johansen') AND end_time IS NULL;
                                                                          QUERY PLAN                                                                          
--------------------------------------------------------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on common_activityinstance  (cost=10157.60..14038.97 rows=45 width=36) (actual time=3923.011..3923.011 rows=0 loops=1)
   Recheck Cond: ((started_by_id = 1370408) AND (end_time IS NULL))
   Rows Removed by Index Recheck: 698
   Filter: (room_name = ANY ('{robcv28,foobartest,noroster,jscode,cv28,johansencouple,lv426,johansenfamily,johansen}'::text[]))
   Heap Blocks: exact=634
   ->  BitmapAnd  (cost=10157.60..10157.60 rows=991 width=0) (actual time=3917.278..3917.278 rows=0 loops=1)
         ->  Bitmap Index Scan on common_activityinstance_started_by_id  (cost=0.00..3282.60 rows=198155 width=0) (actual time=0.245..0.245 rows=927 loops=1)
               Index Cond: (started_by_id = 1370408)
         ->  Bitmap Index Scan on end_time_id  (cost=0.00..6874.73 rows=198155 width=0) (actual time=3915.565..3915.565 rows=1674860 loops=1)
               Index Cond: (end_time IS NULL)
 Planning time: 2.457 ms
 Execution time: 3923.065 ms
(12 rows)

クエリプランが異なる理由がわかりません。これはほんの一例に過ぎません。別のクエリが15分間実行されてから、中止して停止しました。

インデックスに問題があると思ったので、REINDEX DATABASEしかし、それは役に立ちませんでした。

何か案は？

postgresqlpostgresql-9.3postgresql-9.4performanceupgradepostgresql-performance
4
Rob Johansen

データベース全体が影響を受けているようだったので、VACUUM (FULL, ANALYZE)を試すことにしました。完了するまでに50時間4分かかりましたが、完全にの価値がありました。データベースのディスク使用量は1259 GBから747 GB（なんと512 GBの領域を解放）になり、全体のパフォーマンスはアップグレード前の状態に戻りました。

3
Rob Johansen

そこで行われている2つの完全に異なるビットマップスキャンがあります。

   ->  BitmapAnd  (cost=55.63..55.63 rows=1 width=0) (actual time=0.349..0.349 rows=0 loops=1)
         ->  Bitmap Index Scan on common_activityinstance_started_by_id  (cost=0.00..5.53 rows=146 width=0) (actual time=0.122..0.122 rows=927 loops=1)
               Index Cond: (started_by_id = 1370408)
         ->  Bitmap Index Scan on common_activityinstance_room_name_c1f9997a_like  (cost=0.00..49.85 rows=1171 width=0) (actual time=0.171..0.171 rows=926 loops=1)
               Index Cond: (room_name = ANY ('{robcv28,foobartest,noroster,jscode,cv28,johansencouple,lv426,johansenfamily,johansen}'::text[]))
 Total runtime: 1.116 ms

スロー..

   ->  BitmapAnd  (cost=10157.60..10157.60 rows=991 width=0) (actual time=3917.278..3917.278 rows=0 loops=1)
         ->  Bitmap Index Scan on common_activityinstance_started_by_id  (cost=0.00..3282.60 rows=198155 width=0) (actual time=0.245..0.245 rows=927 loops=1)
               Index Cond: (started_by_id = 1370408)
         ->  Bitmap Index Scan on end_time_id  (cost=0.00..6874.73 rows=198155 width=0) (actual time=3915.565..3915.565 rows=1674860 loops=1)
               Index Cond: (end_time IS NULL)

つまり、IS NULL条件は200k行を想定しており、150万行を取得しているため、end_time_idではなくcommon_activityinstance_room_name_c1f9997a_likeでスキャンを使用しています。

クエリを見てみましょう。

EXPLAIN ANALYZE SELECT room_name, id
FROM common_activityinstance
WHERE started_by_id = 1370408
  AND room_name IN ('robcv28', 'foobartest', 'noroster', 'jscode', 'cv28', 'johansencouple', 'lv426', 'johansenfamily', 'johansen')
  AND end_time IS NULL;

ここでの使用例はわかりませんが、end_time IS NOT NULLでroom_nameを検索する頻度はどのくらいですか。私はインデックスend_time_inとcommon_activityinstance_started_by_idをnukeし、代わりにその部分インデックスを作成します（実際にend_timeが設定されている行を気にせず、それらがアーカイブされていると仮定します）。

CREATE INDEX ON common_activityinstance (started_by_id, room_name)
  WHERE end_time IS NULL;
ANALYZE common_activityinstance;
0
Evan Carroll