pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Richard Plotkin <richard@richardplotkin.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: Disk filling, CPU filling, renegade inserts and deletes?
Date: Fri, 22 Apr 2005 09:29:39 -0700
Message-ID: <9c5b2bf6a0f5a0bc0abeb6b6c5cf7973@richardplotkin.com> (raw)
In-Reply-To: <4574.1114030270@sss.pgh.pa.us>
References: <6f4567d4e64297b356e2d71ec392cdae@richardplotkin.com>
	<4574.1114030270@sss.pgh.pa.us>

I've also now tried looking at pg_class.relpages.  I compared the  
results before and after vacuum.  The results stayed the same, except  
for five rows that increased after the vacuum.  Here is the select on  
those rows after the vacuum:

              relname             | relnamespace | reltype | relowner |  
relam | relfilenode | reltablespace | relpages | reltuples |  
reltoastrelid | reltoastidxid | relhasindex | relisshared | relkind |  
relnatts | relchecks | reltriggers | relukeys | relfkeys | relrefs |  
relhasoids | relhaspkey | relhasrules | relhassubclass |    relacl
---------------------------------+--------------+---------+---------- 
+-------+-------------+---------------+----------+----------- 
+---------------+---------------+-------------+-------------+--------- 
+----------+-----------+-------------+----------+----------+--------- 
+------------+------------+-------------+---------------- 
+---------------
  pg_attribute_relid_attnam_index |           11 |       0 |        1 |   
  403 |       16686 |             0 |      292 |     10250 |              
0 |             0 | f           | f           | i       |        2 |     
      0 |           0 |        0 |        0 |       0 | f          | f    
        | f           | f              |
  pg_class_oid_index              |           11 |       0 |        1 |   
  403 |       16690 |             0 |       18 |      2640 |              
0 |             0 | f           | f           | i       |        1 |     
      0 |           0 |        0 |        0 |       0 | f          | f    
        | f           | f              |
  pg_depend_depender_index        |           11 |       0 |        1 |   
  403 |       16701 |             0 |       52 |      6442 |              
0 |             0 | f           | f           | i       |        3 |     
      0 |           0 |        0 |        0 |       0 | f          | f    
        | f           | f              |
  pg_type_oid_index               |           11 |       0 |        1 |   
  403 |       16731 |             0 |        8 |      1061 |              
0 |             0 | f           | f           | i       |        1 |     
      0 |           0 |        0 |        0 |       0 | f          | f    
        | f           | f              |
  pg_depend                       |           11 |   16677 |        1 |   
    0 |       16676 |             0 |       32 |      4200 |              
0 |             0 | t           | f           | r       |        7 |     
      0 |           0 |        0 |        0 |       0 | f          | f    
        | f           | f              | {=r/postgres}



On Apr 20, 2005, at 1:51 PM, Tom Lane wrote:

> Richard Plotkin <richard@richardplotkin.com> writes:
>> I'm having a pretty serious problem with postgresql's performance.
>> Currently, I have a cron task that is set to restart and vacuumdb -faz
>> every six hours.  If that doesn't happen, the disk goes from 10% full
>> to 95% full within 2 days (and it's a 90GB disk...with the database
>> being a 2MB download after dump), and the CPU goes from running at
>> around a 2% load to a 99+% load right away (the stats look like a
>> square wave).
>
> Q: what have you got the FSM parameters set to?
>
> Q: what exactly is bloating?  Without knowing which tables or indexes
> are growing, it's hard to speculate about the exact causes.  Use du and
> oid2name, or look at pg_class.relpages after a plain VACUUM.
>
> It's likely that the real answer is "you need to vacuum more often
> than every six hours", but I'm trying not to jump to conclusions.
>
> 			regards, tom lane
>
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly
>




view thread (18+ messages)  latest in thread

Message-ID: <9c5b2bf6a0f5a0bc0abeb6b6c5cf7973@richardplotkin.com>
Permalink:  ../9c5b2bf6a0f5a0bc0abeb6b6c5cf7973@richardplotkin.com/
Also on:    postgresql.org/message-id/9c5b2bf6a0f5a0bc0abeb6b6c5cf7973@richardplotkin.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: richard@richardplotkin.com, tgl@sss.pgh.pa.us
  Subject: Re: Disk filling, CPU filling, renegade inserts and deletes?
  In-Reply-To: <9c5b2bf6a0f5a0bc0abeb6b6c5cf7973@richardplotkin.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox