0

Version: 13.6

Hi ,

This is a 2 days old issue. Our Postgresql is hosted on AWS RDS Postgresql. Suddenly our free memory dropped from 1300 MB to 23 MB and swap memory increased from 150 mb to 12OO. MB. CPU was little high, read and write iops were high for 2-3 hours , post that low. Average row size from tbl1 was 65 bytes and from tbl2 was 350 bytes.

In performance insight we had only one query which was having most wait on CPU. Below is explain plan of the query. I wanted to understand why this query lead to so much of free memory drop and swap memory increase?

Once we created a combined index on (hotel_id, checkin) include(booking_id), free memory became stable.

Query:

    database1 => EXPLAIN(ANALYZE, VERBOSE, BUFFERS, COSTS, TIMING)
database1-> select l.*, o.* FROM tbl1 o inner join tbl2 l on o.booking_id = l.booking_id where o.checkin = '2022-09-09' and o.hotel_id = 95315 and l.status = 'YES_RM';
                                                                                                                                                               QUERY PLAN                                   
                                                                                                                            
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=3014.65..3077.08 rows=1 width=270) (actual time=71.157..71.159 rows=0 loops=1)
   Output: l.*,o.*
   Inner Unique: true
   Buffers: shared hit=3721 read=170 dirtied=4
   I/O Timings: read=8.173
   ->  Bitmap Heap Scan on public.tbl1 o  (cost=3014.08..3034.13 rows=5 width=74) (actual time=69.447..70.814 rows=8 loops=1)
         Output: o.booking_id, o.checkin, o.created_at, o.hotel_id, o.hotel_time_zone, o.invoice, o.booking_created_at, o.updated_at, o.user_profile_id
         Recheck Cond: ((o.hotel_id = 95315) AND (o.checkin = '2022-09-09'::date))
         Rows Removed by Index Recheck: 508
         Heap Blocks: exact=512
         Buffers: shared hit=3683 read=163
         I/O Timings: read=8.148
         ->  BitmapAnd  (cost=3014.08..3014.08 rows=5 width=0) (actual time=69.182..69.183 rows=0 loops=1)
               Buffers: shared hit=3312 read=19
               I/O Timings: read=7.812
               ->  Bitmap Index Scan on idx33t1pn8h284cj2rg6pa33bxqb  (cost=0.00..167.50 rows=6790 width=0) (actual time=8.550..8.550 rows=3909 loops=1)
                     Index Cond: (o.hotel_id = 95315)
                     Buffers: shared hit=5 read=19
                     I/O Timings: read=7.812
               ->  Bitmap Index Scan on idx6xuah53fdtx4p5afo5cbgul47  (cost=0.00..2846.33 rows=114368 width=0) (actual time=59.391..59.391 rows=297558 loops=1)
                     Index Cond: (o.checkin = '2022-09-09'::date)
                     Buffers: shared hit=3307
   ->  Index Scan using idxicjnq3084849d8vvmnhrornn7 on public. tbl2 l  (cost=0.57..8.59 rows=1 width=204) (actual time=0.042..0.042 rows=0 loops=8)
         Output: l.*
         Index Cond: (l.booking_id = o.booking_id)
         Filter: ((l.status)::text = 'YES_RM'::text)
         Rows Removed by Filter: 1
         Buffers: shared hit=38 read=7 dirtied=4
         I/O Timings: read=0.024
 Planning:
   Buffers: shared hit=335 read=57
   I/O Timings: read=0.180
 Planning Time: 1.472 ms
 Execution Time: 71.254 ms
(34 rows)

After Index creation:

 Nested Loop  (cost=1.14..65.02 rows=1 width=270) (actual time=6.640..6.640 rows=0 loops=1)
   Output: l.*,o.*
   Inner Unique: true
   Buffers: shared hit=54 read=16 dirtied=4
   I/O Timings: read=5.554
   ->  Index Scan using hotel_id_check_in_index on public.tbl1  (cost=0.57..22.07 rows=5 width=74) (actual time=2.105..5.361 rows=11 loops=1)
         Output: o.*
         Index Cond: ((o.hotel_id = 95315) AND (o.checkin = '2022-09-09'::date))
         Buffers: shared hit=8 read=13 dirtied=4
         I/O Timings: read=4.354
   ->  Index Scan using idxicjnq3084849d8vvmnhrornn7 on public.tbl2 l  (cost=0.57..8.59 rows=1 width=204) (actual time=0.116..0.116 rows=0 loops=11)
         Output: l.*
         Index Cond: (l.booking_id = o.booking_id)
         Filter: ((l.tatus)::text = 'YES_RM'::text)
         Rows Removed by Filter: 0
         Buffers: shared hit=46 read=3
         I/O Timings: read=1.199
 Planning:
   Buffers: shared hit=416
 Planning Time: 1.323 ms
 Execution Time: 6.667 ms
(21 rows)

Progman
  • 16,827
  • 6
  • 33
  • 48
Monika Yadav
  • 381
  • 2
  • 12
  • @laurenz albe: pls suggest. – Monika Yadav Sep 12 '22 at 07:01
  • There is no good reason to think the query using the most CPU is also the one using the most memory. Maybe if you had hundreds of instances of this query running at the same time, that could explain the memory usage. But unless you already collected data about that which you haven't shared with us, what can we know about it now that the problem doesn't exist anymore? – jjanes Sep 12 '22 at 14:38

0 Answers0