Hope that you don't find it too distracting, I decided to answer to emails in 
one go.

----

On Saturday 06 September 2003 03:05, Tom Lane wrote:
> indexscans.  If you've also got sequential-scan queries, and you're
> doing many zillion updates between vacuums, the answer is to vacuum
> more often.  A decent rule of thumb is to vacuum whenever you've updated
> more than about 10% of the rows in a table since your last vacuum.

Basically I do this:
1) select about ~700 ID's I have to poll
2) poll them
3) update those 700 rows in that "table" I used (~2700 rows total).

And I do this cycle once per minute, so yes, I've got a zillion updates. 700 
of 2700 is roughly 25%, so I'd have to vacuum once per minute?
The manual actually had a suggestion of vacuuming after big changes, but I 
didn't think it was that bad.

-----

On Saturday 06 September 2003 12:10, Hannu Krosing wrote:
> Could it be that FSM is too small for your vacuum interval ?
>
> Also, you could try running REINDEX (instead of or in addition to plain
> VACUUM) and see if this is is an index issue.

VACUUM ANALYZE helped to lessen the load. Not as much as VACUUM FULL, but 
still bring it down to reasonable level.

> 1. What types of queries do you run, and how often ?

First, cycle posted above; second, every 5 minutes ~40 SELECTs that include 
that table. I left the once-per-minute poller offline this weekend, and the 
CPU usage didn't creep up.

> 2. How is your database tuned (postgresql.conf settings) ?

shared_buffers = 13000   
max_fsm_relations = 100000 
max_fsm_pages = 1000000    
max_locks_per_transaction = 256 
wal_buffers = 64               
sort_mem = 32768  
vacuum_mem = 16384
fsync = false
effective_cache_size = 60000

Using these settings I was able to bring CPU usage down to a more reasonable 
level: http://andri.estpak.ee/cpu1.png
This is much better than the first graph (see http://andri.estpak.ee/cpu0.png 
), but you can still see CPU usage creeping up.
VACUUM FULL was done at 03:00 and 09:00. The small drop at ~12:45 is thanks to 
VACUUM ANALYZE.

If this is the best you can get with postgres right now, then I'll just have 
to increase the frequency of VACUUMing, but that feels like a hackish 
solution :(

> 3. How much memory does your machine have ?

1 gigabyte.


--
andri


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [EMAIL PROTECTED] so that your
      message can get through to the mailing list cleanly

Reply via email to