Thread: Degrading performance
Hello, I have table with slowly degrading performance. Table is special is such way that all its rows are updated every 5 minutes (routers interfaces). vacuum does not help. vacuum full does but I'd like to avoid it. Below I added explain analyze output before and after vacuum full. How could I make that table not to grow? PostgreSQL 7.3.2 on Redhat Linux 7.1. max_fsm_pages=10000 max_fsm_relations=1000. Mindaugas router_db=# explain analyze select * from ifdata; QUERY PLAN ---------------------------------------------------------------------------- ------------------------------- Seq Scan on ifdata (cost=0.00..4894.76 rows=776 width=133) (actual time=31.65..1006.76 rows=776 loops=1) Total runtime: 1007.72 msec (2 rows) router_db=# VACUUM full verbose ifdata; INFO: --Relation public.ifdata-- INFO: Pages 4887: Changed 0, reaped 4883, Empty 0, New 0; Tup 776: Vac 46029, Keep/VTL 0/0, UnUsed 186348, MinLen 130, MaxLen 216; Re-using: Free/Avail. Space 38871060/15072128; EndEmpty/Avail. Pages 2981/1895. CPU 0.33s/0.04u sec elapsed 0.45 sec. INFO: Index ifdata_clientid_key: Pages 2825; Tuples 776: Deleted 46029. CPU 0.23s/0.32u sec elapsed 1.98 sec. INFO: Rel ifdata: Pages: 4887 --> 17; Tuple(s) moved: 776. CPU 0.30s/0.35u sec elapsed 1.65 sec. INFO: Index ifdata_clientid_key: Pages 2825; Tuples 776: Deleted 776. CPU 0.21s/0.04u sec elapsed 0.29 sec. VACUUM router_db=# explain analyze select * from ifdata; QUERY PLAN ---------------------------------------------------------------------------- ------------------------- Seq Scan on ifdata (cost=0.00..24.76 rows=776 width=133) (actual time=0.03..7.53 rows=776 loops=1) Total runtime: 8.17 msec (2 rows)
"Mindaugas Riauba" <mind@bi.lt> writes: > I have table with slowly degrading performance. Table is special is > such way that all its rows are updated every 5 minutes (routers interfaces). > vacuum does not help. vacuum full does but I'd like to avoid it. VACUUM will do the trick, you just need to do it every five minutes or so. I suggest a cron job to vacuum just the one table. > INFO: Rel ifdata: Pages: 4887 --> 17; Tuple(s) moved: 776. > CPU 0.30s/0.35u sec elapsed 1.65 sec. That says you waited way too long to vacuum --- over two hundred update cycles, evidently. regards, tom lane
On Mon, 2 Jun 2003, Tom Lane wrote: > "Mindaugas Riauba" <mind@bi.lt> writes: > > I have table with slowly degrading performance. Table is special is > > such way that all its rows are updated every 5 minutes (routers interfaces). > > vacuum does not help. vacuum full does but I'd like to avoid it. > > VACUUM will do the trick, you just need to do it every five minutes or > so. I suggest a cron job to vacuum just the one table. > > > INFO: Rel ifdata: Pages: 4887 --> 17; Tuple(s) moved: 776. > > CPU 0.30s/0.35u sec elapsed 1.65 sec. > > That says you waited way too long to vacuum --- over two hundred update > cycles, evidently. Don't forget to crank up your fsm settings in $PGDATA/postgresql.conf as well.
"scott.marlowe" <scott.marlowe@ihs.com> writes: > On Mon, 2 Jun 2003, Tom Lane wrote: >>> INFO: Rel ifdata: Pages: 4887 --> 17; Tuple(s) moved: 776. >>> CPU 0.30s/0.35u sec elapsed 1.65 sec. >> >> That says you waited way too long to vacuum --- over two hundred update >> cycles, evidently. > Don't forget to crank up your fsm settings in $PGDATA/postgresql.conf as > well. The table's not very big though. As long as he keeps after it with sufficiently-frequent vacuuming, it won't need much FSM space. regards, tom lane
On Mon, 2 Jun 2003, Tom Lane wrote: > "scott.marlowe" <scott.marlowe@ihs.com> writes: > > On Mon, 2 Jun 2003, Tom Lane wrote: > >>> INFO: Rel ifdata: Pages: 4887 --> 17; Tuple(s) moved: 776. > >>> CPU 0.30s/0.35u sec elapsed 1.65 sec. > >> > >> That says you waited way too long to vacuum --- over two hundred update > >> cycles, evidently. > > > Don't forget to crank up your fsm settings in $PGDATA/postgresql.conf as > > well. > > The table's not very big though. As long as he keeps after it with > sufficiently-frequent vacuuming, it won't need much FSM space. Yeah, but I got the feeling he was updating like 40 rows a second or something. Sufficiently frequent for him may well be constant. :-)