Josh Kupershmidt <schmi...@gmail.com> writes:
>> 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.
What would be expected is for it to ramp up fairly quickly to one entry
per table in the database, and then stabilize. Maybe the 1.2GB figure
represents the fallout from some strange event rather than a gradual
leakage.
> 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.
Do you have a copy of the 1.2GB file and would you be willing to send me
it if so? There shouldn't be any especially private info in there, just
table OIDs and access counts. (1.2GB would be a lot of data to mail but
I bet it gzips down to a lot less.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
