Обсуждение: auto vacuum doens't appear to be working
We have a bytea column where we store large attachments (ie pdf file). every so often (2 weekly) we replace the large a attachment (5-15mb) with a much smaller binary file (15k). when I run SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != '' I get a value of 104995 which I interpret to mean I have 104GB of stored data in the database and this value has remained relatively static (+/- 1GB) over the past couple of weeks. We I to a df -h on the filesystem holding the database cluster I get a usage of 140GB. Again I interpret this to mean I have nearly 35GB of "uncleaned" data. Is this a case where I should be running the vacuum manually or is auto vacuum all that should be necessary to keep track and mark the updated tuple space ready for re-use. thanks -- Warren Little Chief Technology Officer Meridias Capital, Inc 1006 Atherton Dr Salt Lake City, UT 84123 ph. 866.369.7763
Warren Little <warren.little@meridiascapital.com> writes: > when I run > SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != '' > I get a value of 104995 which I interpret to mean I have 104GB of stored data > in the database and this value has remained relatively static (+/- 1GB) over > the past couple of weeks. > We I to a df -h on the filesystem holding the database cluster I get a usage > of 140GB. Again I interpret this to mean I have nearly 35GB of "uncleaned" > data. That conclusion is entirely incorrect --- relpages should be the whole space usage for each table, assuming it's up-to-date (it might not be). However a query done as above would account only for the current database; perhaps the other space is in other databases? If you've had database crashes in the past, there could be problems with unreferenced files. Or the bloat could be in pg_xlog or one of the other overhead directories, or not Postgres' fault at all considering that you're examining the whole filesystem. A single "df" number won't help you pin it down, you need to do more careful analysis. I'd start with a directory-by-directory "du" listing, and check individual files if necessary (contrib/oid2name or contrib/pgstattuple might help). For background see http://www.postgresql.org/docs/8.1/static/storage.html (adjust for your PG version) regards, tom lane
Also, remember that a regular vacuum won't actually free any disk space*, it only marks it as re-useable in the table. * OK, technically it will reclaim space from the very end of the table * in certain circumstances, but in reality it's pretty rare for that to * happen. On Fri, Jun 30, 2006 at 11:09:14AM -0400, Tom Lane wrote: > Warren Little <warren.little@meridiascapital.com> writes: > > when I run > > SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != '' > > I get a value of 104995 which I interpret to mean I have 104GB of stored data > > in the database and this value has remained relatively static (+/- 1GB) over > > the past couple of weeks. > > We I to a df -h on the filesystem holding the database cluster I get a usage > > of 140GB. Again I interpret this to mean I have nearly 35GB of "uncleaned" > > data. > > That conclusion is entirely incorrect --- relpages should be the whole > space usage for each table, assuming it's up-to-date (it might not be). > However a query done as above would account only for the current > database; perhaps the other space is in other databases? If you've had > database crashes in the past, there could be problems with unreferenced > files. Or the bloat could be in pg_xlog or one of the other overhead > directories, or not Postgres' fault at all considering that you're > examining the whole filesystem. A single "df" number won't help you pin > it down, you need to do more careful analysis. I'd start with a > directory-by-directory "du" listing, and check individual files if > necessary (contrib/oid2name or contrib/pgstattuple might help). For > background see > http://www.postgresql.org/docs/8.1/static/storage.html > (adjust for your PG version) > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461