| From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: [Solved] 8.3 Stats Collector Stuck at 100% CPU |
| Date: | 2010-04-01 20:01:01 |
| Message-ID: | w2j4ec1cf761004011301zb63f2c6dj7b2737174778ff57@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> Hm. It sounds like you are "leaking" stats collector table entries for
> some reason. It would be good to fix the underlying problem rather than
> just resign yourself to a manual workaround. Is there anything unusual
> about your workload that might trigger this?
Don't think the database setup is that unusual. I did overestimate how
quickly pgstat.stat is growing; it's only gone up to 800KB in the 20
hours since I ran pg_stat_reset(). I thought it was growing 4MB per
day because last night it had grown to 500KB in just 3 hours. Also, it
had ballooned to 1.2 GB after running for around a year, I think.
Relevant stats-related info I can think of:
* default_statistics_target = 10
* I don't think any tables have had ALTER TABLE SET STATISTICS done
* the two really active databases have 2300 and 490 rows in pg_class
* mostly bulk updates/inserts
* PGDATA is 1.6 TB
If there's some useful debugging info on the stats collector process I
can gather from the server, I'd be happy to try.
Josh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-04-01 20:22:52 | Re: [Solved] 8.3 Stats Collector Stuck at 100% CPU |
| Previous Message | Peter Bex | 2010-04-01 19:03:03 | Array value syntax and escaping |