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
