Lists: | pgsql-performance |
---|
From: | "Mindaugas Riauba" <mind(at)bi(dot)lt> |
---|---|
To: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Degrading performance |
Date: | 2003-06-02 05:33:38 |
Message-ID: | 005a01c328c8$885b9760$f20214ac@bite.lt |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-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)
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mindaugas Riauba" <mind(at)bi(dot)lt> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Degrading performance |
Date: | 2003-06-02 13:36:31 |
Message-ID: | 7850.1054560991@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-performance |
"Mindaugas Riauba" <mind(at)bi(dot)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
From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mindaugas Riauba <mind(at)bi(dot)lt>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Degrading performance |
Date: | 2003-06-02 16:34:43 |
Message-ID: | Pine.LNX.4.33.0306021034190.11997-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-performance |
On Mon, 2 Jun 2003, Tom Lane wrote:
> "Mindaugas Riauba" <mind(at)bi(dot)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.
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
Cc: | Mindaugas Riauba <mind(at)bi(dot)lt>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Degrading performance |
Date: | 2003-06-02 17:25:22 |
Message-ID: | 9538.1054574722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-performance |
"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)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
From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mindaugas Riauba <mind(at)bi(dot)lt>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Degrading performance |
Date: | 2003-06-02 17:42:48 |
Message-ID: | Pine.LNX.4.33.0306021142180.12320-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-performance |
On Mon, 2 Jun 2003, Tom Lane wrote:
> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)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. :-)