2010-09-20 22:08:53 +02:00
|
|
|
<!-- doc/src/sgml/diskusage.sgml -->
|
2002-06-13 07:15:22 +02:00
|
|
|
|
|
|
|
<chapter id="diskusage">
|
|
|
|
<title>Monitoring Disk Usage</title>
|
|
|
|
|
2002-10-17 00:06:33 +02:00
|
|
|
<para>
|
2002-11-15 04:11:18 +01:00
|
|
|
This chapter discusses how to monitor the disk usage of a
|
2017-10-09 03:44:17 +02:00
|
|
|
<productname>PostgreSQL</productname> database system.
|
2002-10-17 00:06:33 +02:00
|
|
|
</para>
|
|
|
|
|
2002-06-13 07:15:22 +02:00
|
|
|
<sect1 id="disk-usage">
|
2011-01-29 19:00:18 +01:00
|
|
|
<title>Determining Disk Usage</title>
|
2002-06-13 07:15:22 +02:00
|
|
|
|
|
|
|
<indexterm zone="disk-usage">
|
|
|
|
<primary>disk usage</primary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Each table has a primary heap disk file where most of the data is
|
2004-12-01 20:00:56 +01:00
|
|
|
stored. If the table has any columns with potentially-wide values,
|
2017-10-09 03:44:17 +02:00
|
|
|
there also might be a <acronym>TOAST</acronym> file associated with the table,
|
2004-12-01 20:00:56 +01:00
|
|
|
which is used to store values too wide to fit comfortably in the main
|
2017-11-23 15:39:47 +01:00
|
|
|
table (see <xref linkend="storage-toast"/>). There will be one valid index
|
2017-10-09 03:44:17 +02:00
|
|
|
on the <acronym>TOAST</acronym> table, if present. There also might be indexes
|
2013-07-03 20:24:09 +02:00
|
|
|
associated with the base table. Each table and index is stored in a
|
|
|
|
separate disk file — possibly more than one file, if the file would
|
|
|
|
exceed one gigabyte. Naming conventions for these files are described
|
2017-11-23 15:39:47 +01:00
|
|
|
in <xref linkend="storage-file-layout"/>.
|
2002-06-13 07:15:22 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2010-02-07 21:48:13 +01:00
|
|
|
You can monitor disk space in three ways:
|
2017-11-23 15:39:47 +01:00
|
|
|
using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
|
|
|
|
using the <xref linkend="oid2name"/> module, or
|
2010-02-07 21:48:13 +01:00
|
|
|
using manual inspection of the system catalogs.
|
|
|
|
The SQL functions are the easiest to use and are generally recommended.
|
|
|
|
The remainder of this section shows how to do it by inspection of the
|
|
|
|
system catalogs.
|
2005-07-29 16:47:04 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
Using <application>psql</application> on a recently vacuumed or analyzed database,
|
2002-06-21 21:06:44 +02:00
|
|
|
you can issue queries to see the disk usage of any table:
|
2002-06-13 07:15:22 +02:00
|
|
|
<programlisting>
|
2010-02-07 21:48:13 +01:00
|
|
|
SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
|
2003-03-24 15:32:51 +01:00
|
|
|
|
2013-07-03 20:24:09 +02:00
|
|
|
pg_relation_filepath | relpages
|
2010-02-07 21:48:13 +01:00
|
|
|
----------------------+----------
|
|
|
|
base/16384/16806 | 60
|
2002-06-13 07:15:22 +02:00
|
|
|
(1 row)
|
|
|
|
</programlisting>
|
2017-10-09 03:44:17 +02:00
|
|
|
Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
|
|
|
|
is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
|
|
|
|
a few DDL commands such as <command>CREATE INDEX</command>.) The file path name
|
2010-02-07 21:48:13 +01:00
|
|
|
is of interest if you want to examine the table's disk file directly.
|
2002-06-13 07:15:22 +02:00
|
|
|
</para>
|
|
|
|
|
2003-03-24 15:32:51 +01:00
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
To show the space used by <acronym>TOAST</acronym> tables, use a query
|
2004-12-01 20:00:56 +01:00
|
|
|
like the following:
|
2002-06-13 07:15:22 +02:00
|
|
|
<programlisting>
|
2003-03-24 15:32:51 +01:00
|
|
|
SELECT relname, relpages
|
2010-02-03 18:25:06 +01:00
|
|
|
FROM pg_class,
|
|
|
|
(SELECT reltoastrelid
|
|
|
|
FROM pg_class
|
|
|
|
WHERE relname = 'customer') AS ss
|
|
|
|
WHERE oid = ss.reltoastrelid OR
|
2013-07-03 20:24:09 +02:00
|
|
|
oid = (SELECT indexrelid
|
|
|
|
FROM pg_index
|
|
|
|
WHERE indrelid = ss.reltoastrelid)
|
2010-02-03 18:25:06 +01:00
|
|
|
ORDER BY relname;
|
2003-03-24 15:32:51 +01:00
|
|
|
|
2013-07-03 20:24:09 +02:00
|
|
|
relname | relpages
|
2002-06-13 07:15:22 +02:00
|
|
|
----------------------+----------
|
|
|
|
pg_toast_16806 | 0
|
|
|
|
pg_toast_16806_index | 1
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-03-24 15:32:51 +01:00
|
|
|
You can easily display index sizes, too:
|
2002-06-13 07:15:22 +02:00
|
|
|
<programlisting>
|
2003-03-24 15:32:51 +01:00
|
|
|
SELECT c2.relname, c2.relpages
|
2010-02-03 18:25:06 +01:00
|
|
|
FROM pg_class c, pg_class c2, pg_index i
|
|
|
|
WHERE c.relname = 'customer' AND
|
|
|
|
c.oid = i.indrelid AND
|
|
|
|
c2.oid = i.indexrelid
|
|
|
|
ORDER BY c2.relname;
|
2003-03-24 15:32:51 +01:00
|
|
|
|
2013-07-03 20:24:09 +02:00
|
|
|
relname | relpages
|
2002-06-13 07:15:22 +02:00
|
|
|
----------------------+----------
|
|
|
|
customer_id_indexdex | 26
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2003-03-24 15:32:51 +01:00
|
|
|
It is easy to find your largest tables and indexes using this
|
|
|
|
information:
|
2002-06-13 07:15:22 +02:00
|
|
|
<programlisting>
|
2010-02-03 18:25:06 +01:00
|
|
|
SELECT relname, relpages
|
|
|
|
FROM pg_class
|
|
|
|
ORDER BY relpages DESC;
|
2003-03-24 15:32:51 +01:00
|
|
|
|
2013-07-03 20:24:09 +02:00
|
|
|
relname | relpages
|
2002-06-13 07:15:22 +02:00
|
|
|
----------------------+----------
|
|
|
|
bigtable | 3290
|
|
|
|
customer | 3144
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
</sect1>
|
2002-10-17 00:06:33 +02:00
|
|
|
|
|
|
|
<sect1 id="disk-full">
|
|
|
|
<title>Disk Full Failure</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
The most important disk monitoring task of a database administrator
|
2010-02-03 18:25:06 +01:00
|
|
|
is to make sure the disk doesn't become full. A filled data disk will
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
not result in data corruption, but it might prevent useful activity
|
2004-12-01 20:00:56 +01:00
|
|
|
from occurring. If the disk holding the WAL files grows full, database
|
Update documentation on may/can/might:
Standard English uses "may", "can", and "might" in different ways:
may - permission, "You may borrow my rake."
can - ability, "I can lift that log."
might - possibility, "It might rain today."
Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice. Similarly, "It may crash" is better stated, "It might crash".
Also update two error messages mentioned in the documenation to match.
2007-01-31 21:56:20 +01:00
|
|
|
server panic and consequent shutdown might occur.
|
2002-10-17 00:06:33 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
If you cannot free up additional space on the disk by deleting
|
2004-06-21 06:06:07 +02:00
|
|
|
other things, you can move some of the database files to other file
|
|
|
|
systems by making use of tablespaces. See <xref
|
2017-11-23 15:39:47 +01:00
|
|
|
linkend="manage-ag-tablespaces"/> for more information about that.
|
2002-10-17 00:06:33 +02:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<tip>
|
|
|
|
<para>
|
|
|
|
Some file systems perform badly when they are almost full, so do
|
2004-06-21 06:06:07 +02:00
|
|
|
not wait until the disk is completely full to take action.
|
2002-10-17 00:06:33 +02:00
|
|
|
</para>
|
|
|
|
</tip>
|
2004-12-28 20:08:58 +01:00
|
|
|
|
|
|
|
<para>
|
|
|
|
If your system supports per-user disk quotas, then the database
|
|
|
|
will naturally be subject to whatever quota is placed on the user
|
|
|
|
the server runs as. Exceeding the quota will have the same bad
|
2010-02-03 18:25:06 +01:00
|
|
|
effects as running out of disk space entirely.
|
2004-12-28 20:08:58 +01:00
|
|
|
</para>
|
2002-10-17 00:06:33 +02:00
|
|
|
</sect1>
|
2002-06-13 07:15:22 +02:00
|
|
|
</chapter>
|