On Oct 15, 2012, at 2:27 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Tore Halset <hal...@pvv.ntnu.no> writes: >> On this box I drop a 80GB database each night followed by a restore of a >> similar sized database. It is a restore of our production database to a >> development server. This box is running 9.2rc1 (sorry). > >> du and df reported quite different numbers and lsof show that autovacuum is >> holding lots of deleted files. After killing the autovacuum daemon, some >> disk space was restored and the du and df numbers was more equal. > >> autovacuum hold roughly 100GB of deleted files. This running PostgreSQL >> instance has dumped/restored the 80GB database ~20 times. > > Hm. I've been able to reproduce some leakage of file descriptors in the > autovac launcher, but it required (a) fairly small shared_buffers and > (b) very heavy update activity on large tables. So I'm not sure that it > would explain the consistent leakage you seem to be seeing. Can you > tell us more about your usage pattern on the development server?
A cron job dropdb one of the databases and createdb it and then pg_restore. Roughly 80GB dump. In addition to that database, we have some other copies that are used by some java clients. Only light usage. Not any stored procedures, but a lot of blobs. None of the blobs are over 5MB in size. lsof show that both autovacuum and idle postgres-processes hold references to deleted files. Out production PostgreSQL running a 9.1 variant does not have this problem. It does not have the nightly dropdb/createdb/pg_restore, but otherwise similar usage patterins. It is also configured to use more memory. > What > nondefault settings are you using on it? it is pretty default. max_connections = 100 shared_buffers = 32MB Regards, Tore Halset. -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
