@@ -7282,4 +7282,147 @@ if (TRACE_POSTGRESQL_TRANSACTION_START_ENABLED())
7282
7282
7283
7283
</sect1>
7284
7284
7285
+ <sect1 id="diskusage">
7286
+ <title>Monitoring Disk Usage</title>
7287
+
7288
+ <para>
7289
+ This section discusses how to monitor the disk usage of a
7290
+ <productname>PostgreSQL</productname> database system.
7291
+ </para>
7292
+
7293
+ <sect2 id="disk-usage">
7294
+ <title>Determining Disk Usage</title>
7295
+
7296
+ <indexterm zone="disk-usage">
7297
+ <primary>disk usage</primary>
7298
+ </indexterm>
7299
+
7300
+ <para>
7301
+ Each table has a primary heap disk file where most of the data is
7302
+ stored. If the table has any columns with potentially-wide values,
7303
+ there also might be a <acronym>TOAST</acronym> file associated with the table,
7304
+ which is used to store values too wide to fit comfortably in the main
7305
+ table (see <xref linkend="storage-toast"/>). There will be one valid index
7306
+ on the <acronym>TOAST</acronym> table, if present. There also might be indexes
7307
+ associated with the base table. Each table and index is stored in a
7308
+ separate disk file — possibly more than one file, if the file would
7309
+ exceed one gigabyte. Naming conventions for these files are described
7310
+ in <xref linkend="storage-file-layout"/>.
7311
+ </para>
7312
+
7313
+ <para>
7314
+ You can monitor disk space in three ways:
7315
+ using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>,
7316
+ using the <xref linkend="oid2name"/> module, or
7317
+ using manual inspection of the system catalogs.
7318
+ The SQL functions are the easiest to use and are generally recommended.
7319
+ The remainder of this section shows how to do it by inspection of the
7320
+ system catalogs.
7321
+ </para>
7322
+
7323
+ <para>
7324
+ Using <application>psql</application> on a recently vacuumed or analyzed
7325
+ database, you can issue queries to see the disk usage of any table:
7326
+ <programlisting>
7327
+ SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';
7328
+
7329
+ pg_relation_filepath | relpages
7330
+ ----------------------+----------
7331
+ base/16384/16806 | 60
7332
+ (1 row)
7333
+ </programlisting>
7334
+ Each page is typically 8 kilobytes. (Remember, <structfield>relpages</structfield>
7335
+ is only updated by <command>VACUUM</command>, <command>ANALYZE</command>, and
7336
+ a few DDL commands such as <command>CREATE INDEX</command>.) The file path name
7337
+ is of interest if you want to examine the table's disk file directly.
7338
+ </para>
7339
+
7340
+ <para>
7341
+ To show the space used by <acronym>TOAST</acronym> tables, use a query
7342
+ like the following:
7343
+ <programlisting>
7344
+ SELECT relname, relpages
7345
+ FROM pg_class,
7346
+ (SELECT reltoastrelid
7347
+ FROM pg_class
7348
+ WHERE relname = 'customer') AS ss
7349
+ WHERE oid = ss.reltoastrelid OR
7350
+ oid = (SELECT indexrelid
7351
+ FROM pg_index
7352
+ WHERE indrelid = ss.reltoastrelid)
7353
+ ORDER BY relname;
7354
+
7355
+ relname | relpages
7356
+ ----------------------+----------
7357
+ pg_toast_16806 | 0
7358
+ pg_toast_16806_index | 1
7359
+ </programlisting>
7360
+ </para>
7361
+
7362
+ <para>
7363
+ You can easily display index sizes, too:
7364
+ <programlisting>
7365
+ SELECT c2.relname, c2.relpages
7366
+ FROM pg_class c, pg_class c2, pg_index i
7367
+ WHERE c.relname = 'customer' AND
7368
+ c.oid = i.indrelid AND
7369
+ c2.oid = i.indexrelid
7370
+ ORDER BY c2.relname;
7371
+
7372
+ relname | relpages
7373
+ -------------------+----------
7374
+ customer_id_index | 26
7375
+ </programlisting>
7376
+ </para>
7377
+
7378
+ <para>
7379
+ It is easy to find your largest tables and indexes using this
7380
+ information:
7381
+ <programlisting>
7382
+ SELECT relname, relpages
7383
+ FROM pg_class
7384
+ ORDER BY relpages DESC;
7385
+
7386
+ relname | relpages
7387
+ ----------------------+----------
7388
+ bigtable | 3290
7389
+ customer | 3144
7390
+ </programlisting>
7391
+ </para>
7392
+ </sect2>
7393
+
7394
+ <sect2 id="disk-full">
7395
+ <title>Disk Full Failure</title>
7396
+
7397
+ <para>
7398
+ The most important disk monitoring task of a database administrator
7399
+ is to make sure the disk doesn't become full. A filled data disk will
7400
+ not result in data corruption, but it might prevent useful activity
7401
+ from occurring. If the disk holding the WAL files grows full, database
7402
+ server panic and consequent shutdown might occur.
7403
+ </para>
7404
+
7405
+ <para>
7406
+ If you cannot free up additional space on the disk by deleting
7407
+ other things, you can move some of the database files to other file
7408
+ systems by making use of tablespaces. See <xref
7409
+ linkend="manage-ag-tablespaces"/> for more information about that.
7410
+ </para>
7411
+
7412
+ <tip>
7413
+ <para>
7414
+ Some file systems perform badly when they are almost full, so do
7415
+ not wait until the disk is completely full to take action.
7416
+ </para>
7417
+ </tip>
7418
+
7419
+ <para>
7420
+ If your system supports per-user disk quotas, then the database
7421
+ will naturally be subject to whatever quota is placed on the user
7422
+ the server runs as. Exceeding the quota will have the same bad
7423
+ effects as running out of disk space entirely.
7424
+ </para>
7425
+ </sect2>
7426
+ </sect1>
7427
+
7285
7428
</chapter>
0 commit comments