Re: Serious issues with CPU usage

От: Andri Saar
Тема: Re: Serious issues with CPU usage
Дата: ,
Msg-id: 200309081350.23312.andris@estpak.ee
(см: обсуждение, исходный текст)
Ответ на: Re: Serious issues with CPU usage  (Tom Lane)
Ответы: Re: Serious issues with CPU usage  ("Shridhar Daithankar")
Re: Serious issues with CPU usage  (Manfred Koizar)
Re: Serious issues with CPU usage  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

Serious issues with CPU usage  (<>, )
 Re: Serious issues with CPU usage  (Tom Lane, )
  Re: Serious issues with CPU usage  (Andri Saar, )
   Re: Serious issues with CPU usage  ("Shridhar Daithankar", )
   Re: Serious issues with CPU usage  (Manfred Koizar, )
   Re: Serious issues with CPU usage  (Tom Lane, )
    Re: Serious issues with CPU usage  (Andri Saar, )
     Re: Serious issues with CPU usage  ("Shridhar Daithankar", )
 Re: Serious issues with CPU usage  (Hannu Krosing, )

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



В списке pgsql-performance по дате сообщения:

От: "scott.marlowe"
Дата:
Сообщение: Re: slow plan for min/max
От: Neil Conway
Дата:
Сообщение: Re: slow plan for min/max