Обсуждение: Re: Disk Space issue
Hi, I think you have a lot DML operation in your database and you are not vacuuming your database . So try to execute command vacuum analyze <<table name >>; in your schema where you are facing problem. -----Original Message----- From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Devendra Singh Rawat Sent: Wednesday, June 11, 2008 5:07 AM To: pgsql-admin@postgresql.org Subject: [ADMIN] Disk Space issue Hi, We are using PostgreSQL 7.4.5 and facing issues with increasing disk space. Here is some information about our configuration. The data dump size is around 3 GB. And it is occupying around 120GB on the disk. When we recreate the database from data dump it takes around 3.5GB of disk space. But the database size increases by 1 GB daily though actual data added maybe in KB. We are not able to decipher as to what is causing this increase. Suggestions on the likely problems will be appreciated. Regards, Devendra **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Hi All,
I recreated my database this morning with a dump size of 3GB, which after database creation occupied 3.5GB on disk.
And in less than 8 hours it has bloated to additional 3.7GB (the disk size now is 7.2GB).
There are quite a few DML operations which are happening on my DB.
SELECT relname, relpages FROM pg_class ORDER BY relpages DESC;
relname | relpages
-------------------------------------------------------------+----------
< table1 > | 180676
< table2 > | 22828
< table3 > | 13469
< table4 > | 9174
< table5 > | 7246
< table6 > | 3865
< table7 > | 2384
< table8 > | 2013
< table9 > | 1836
< table10 > | 1356
< table11 > | 1349
< table12 > | 1025
< table13 > | 910
< table14 > | 896
< table15 > | 797
< table16 > | 708
< table17 > | 665
< table18 > | 601
< table19 > | 407
< table20 > | 374
Regards,
Devendra
-----Original Message-----
From: Praveen Kumar (TUV) [mailto:praveen.k@renaissance-it.com]
Sent: Wednesday, 11 June 2008 4:15 PM
To: Devendra Singh Rawat; pgsql-admin@postgresql.org
Subject: RE: [ADMIN] Disk Space issue
Hi,
I think you have a lot DML operation in your database and you are not
vacuuming your database . So try to execute command vacuum analyze
<<table name >>; in your schema where you are facing problem.
-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of Devendra Singh
Rawat
Sent: Wednesday, June 11, 2008 5:07 AM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Disk Space issue
Hi,
We are using PostgreSQL 7.4.5 and facing issues with increasing disk
space.
Here is some information about our configuration.
The data dump size is around 3 GB. And it is occupying around 120GB on
the disk. When we recreate the database from data dump it takes around
3.5GB of disk space.
But the database size increases by 1 GB daily though actual data added
maybe in KB. We are not able to decipher as to what is causing this
increase.
Suggestions on the likely problems will be appreciated.
Regards,
Devendra
**************** CAUTION - Disclaimer ***************** This e-mail
contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the
use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further,
you are not to copy, disclose, or distribute this e-mail or its contents
to any other person and any such actions are unlawful. This e-mail may
contain viruses. Infosys has taken every reasonable precaution to
minimize this risk, but is not liable for any damage you may sustain as
a result of any virus in this e-mail. You should carry out your own
virus checks before opening the e-mail or attachment. Infosys reserves
the right to monitor and review the content of all messages sent to or
from this e-mail address. Messages sent to or from this e-mail address
may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make
changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
On Wed, Jun 11, 2008 at 1:12 PM, Devendra Singh Rawat <Devendra_Rawat@infosys.com> wrote: > Hi All, > > I recreated my database this morning with a dump size of 3GB, which after database creation occupied 3.5GB on disk. > And in less than 8 hours it has bloated to additional 3.7GB (the disk size now is 7.2GB). > Check if you have autovacuum enabled and configured properly. Btw, you should seriously consider upgrading to newer release like 8.3 which significantly improves performance for high UPDATE work load. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Devendra Singh Rawat wrote: > Hi All, > > I recreated my database this morning with a dump size of 3GB, which after database creation occupied 3.5GB on disk. > And in less than 8 hours it has bloated to additional 3.7GB (the disk size now is 7.2GB). > > There are quite a few DML operations which are happening on my DB. This is a typical case where you can experience a good deal of index bloat. I would recommend installing the dbsize contrib module, and monitor the size of the relations (tables and indexes) in your database, to see which relations in particular is growing rapidly in size. Once you've identified the culprit, you could use reindex or cluster to reclaim the dead space. Note that reindex and cluster require fairly extensive locks, so not so good to use on a busy database during working hours. -- Tommy Gildseth
On Wed, Jun 11, 2008 at 1:42 AM, Devendra Singh Rawat <Devendra_Rawat@infosys.com> wrote: > Hi All, > > I recreated my database this morning with a dump size of 3GB, which after database creation occupied 3.5GB on disk. > And in less than 8 hours it has bloated to additional 3.7GB (the disk size now is 7.2GB). > > There are quite a few DML operations which are happening on my DB. Note that 7.4 was pretty poor at recovering space from the catalogs and the associated indexes. It could be that you would need to shut down each night and vacuum full the catalogs in single user mode to recover the space. But it's been a while since I ran something older than 8.1 or so, so it might have been an even older version that had those issues.
On Mittwoch, 11. Juni 2008 Devendra Singh Rawat wrote: > And in less than 8 hours it has bloated to additional 3.7GB (the disk > size now is 7.2GB). > > There are quite a few DML operations which are happening on my DB. > > SELECT relname, relpages FROM pg_class ORDER BY relpages DESC; > relname | relpages > -------------------------------------------------------------+------- >--- < table1 > | 180676 And after VACUUM FULL, is it small again? Maybe you need to run it 2-3 times a day, for your specific workload. mfg zmi -- // Michael Monnerie, Ing.BSc ----- http://it-management.at // Tel: 0660 / 415 65 31 .network.your.ideas. // PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import" // Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4 // Keyserver: www.keyserver.net Key-ID: 1C1209B4