mirror of
https://github.com/postgres/postgres.git
synced 2026-02-17 01:31:07 -05:00
b9b8831ad6
of shared or nailed system catalogs. This has two key benefits: * The new CLUSTER-based VACUUM FULL can be applied safely to all catalogs. * We no longer have to use an unsafe reindex-in-place approach for reindexing shared catalogs. CLUSTER on nailed catalogs now works too, although I left it disabled on shared catalogs because the resulting pg_index.indisclustered update would only be visible in one database. Since reindexing shared system catalogs is now fully transactional and crash-safe, the former special cases in REINDEX behavior have been removed; shared catalogs are treated the same as non-shared. This commit does not do anything about the recently-discussed problem of deadlocks between VACUUM FULL/CLUSTER on a system catalog and other concurrent queries; will address that in a separate patch. As a stopgap, parallel_schedule has been tweaked to run vacuum.sql by itself, to avoid such failures during the regression tests.
145 lines
4.7 KiB
Text
145 lines
4.7 KiB
Text
<!-- $PostgreSQL: pgsql/doc/src/sgml/diskusage.sgml,v 1.20 2010/02/07 20:48:09 tgl Exp $ -->
|
|
|
|
<chapter id="diskusage">
|
|
<title>Monitoring Disk Usage</title>
|
|
|
|
<para>
|
|
This chapter discusses how to monitor the disk usage of a
|
|
<productname>PostgreSQL</> database system.
|
|
</para>
|
|
|
|
<sect1 id="disk-usage">
|
|
<title>Determining Disk Usage</Title>
|
|
|
|
<indexterm zone="disk-usage">
|
|
<primary>disk usage</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
Each table has a primary heap disk file where most of the data is
|
|
stored. If the table has any columns with potentially-wide values,
|
|
there also might be a <acronym>TOAST</> file associated with the table,
|
|
which is used to store values too wide to fit comfortably in the main
|
|
table (see <xref linkend="storage-toast">). There will be one index on the
|
|
<acronym>TOAST</> table, if present. There also might be indexes 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 in <xref
|
|
linkend="storage-file-layout">.
|
|
</para>
|
|
|
|
<para>
|
|
You can monitor disk space in three ways:
|
|
using the SQL functions listed in <xref linkend="functions-admin-dbsize">,
|
|
using the tools in <filename>contrib/oid2name</>, or
|
|
using manual inspection of the system catalogs.
|
|
The SQL functions are the easiest to use and are generally recommended.
|
|
<filename>contrib/oid2name</> is described in <xref linkend="oid2name">.
|
|
The remainder of this section shows how to do it by inspection of the
|
|
system catalogs.
|
|
</para>
|
|
|
|
<para>
|
|
Using <application>psql</> on a recently vacuumed or analyzed database,
|
|
you can issue queries to see the disk usage of any table:
|
|
<programlisting>
|
|
SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
|
|
|
|
pg_relation_filepath | relpages
|
|
----------------------+----------
|
|
base/16384/16806 | 60
|
|
(1 row)
|
|
</programlisting>
|
|
Each page is typically 8 kilobytes. (Remember, <structfield>relpages</>
|
|
is only updated by <command>VACUUM</>, <command>ANALYZE</>, and
|
|
a few DDL commands such as <command>CREATE INDEX</>.) The file pathname
|
|
is of interest if you want to examine the table's disk file directly.
|
|
</para>
|
|
|
|
<para>
|
|
To show the space used by <acronym>TOAST</> tables, use a query
|
|
like the following:
|
|
<programlisting>
|
|
SELECT relname, relpages
|
|
FROM pg_class,
|
|
(SELECT reltoastrelid
|
|
FROM pg_class
|
|
WHERE relname = 'customer') AS ss
|
|
WHERE oid = ss.reltoastrelid OR
|
|
oid = (SELECT reltoastidxid
|
|
FROM pg_class
|
|
WHERE oid = ss.reltoastrelid)
|
|
ORDER BY relname;
|
|
|
|
relname | relpages
|
|
----------------------+----------
|
|
pg_toast_16806 | 0
|
|
pg_toast_16806_index | 1
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
You can easily display index sizes, too:
|
|
<programlisting>
|
|
SELECT c2.relname, c2.relpages
|
|
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;
|
|
|
|
relname | relpages
|
|
----------------------+----------
|
|
customer_id_indexdex | 26
|
|
</programlisting>
|
|
</para>
|
|
|
|
<para>
|
|
It is easy to find your largest tables and indexes using this
|
|
information:
|
|
<programlisting>
|
|
SELECT relname, relpages
|
|
FROM pg_class
|
|
ORDER BY relpages DESC;
|
|
|
|
relname | relpages
|
|
----------------------+----------
|
|
bigtable | 3290
|
|
customer | 3144
|
|
</programlisting>
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="disk-full">
|
|
<title>Disk Full Failure</title>
|
|
|
|
<para>
|
|
The most important disk monitoring task of a database administrator
|
|
is to make sure the disk doesn't become full. A filled data disk will
|
|
not result in data corruption, but it might prevent useful activity
|
|
from occurring. If the disk holding the WAL files grows full, database
|
|
server panic and consequent shutdown might occur.
|
|
</para>
|
|
|
|
<para>
|
|
If you cannot free up additional space on the disk by deleting
|
|
other things, you can move some of the database files to other file
|
|
systems by making use of tablespaces. See <xref
|
|
linkend="manage-ag-tablespaces"> for more information about that.
|
|
</para>
|
|
|
|
<tip>
|
|
<para>
|
|
Some file systems perform badly when they are almost full, so do
|
|
not wait until the disk is completely full to take action.
|
|
</para>
|
|
</tip>
|
|
|
|
<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
|
|
effects as running out of disk space entirely.
|
|
</para>
|
|
</sect1>
|
|
</chapter>
|