バージョンごとのドキュメント一覧

27.6. Monitoring Disk Usage #

This section discusses how to monitor the disk usage of a <productname>PostgreSQL</productname> database system. 《機械翻訳》この節では、PostgreSQLデータベースシステムのディスク使用量を監視する方法について説明します。

27.6.1. Determining Disk Usage #

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</acronym> 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 valid index on the <acronym>TOAST</acronym> table, if present. There also might be indexes associated with the base table. Each table and index is stored in a separate disk file &mdash; 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"/>. 《機械翻訳》各テーブルには、データの大部分が格納されるプライマリヒープディスクファイルがあります。 テーブルに広い値を持つ可能性のある列がある場合、テーブルに関連付けられたTOASTファイルもあり、これはメインテーブルに収まりきらない広すぎる値を格納するために使用されます(65.2を参照してください)。 TOASTテーブルに有効なインデックスが存在する場合、そのインデックスが1つ存在します。 また、ベース・テーブルに関連付けられたインデックスがある場合もあります。 各テーブルとインデックスは、別々のディスク・ファイルに格納されます。 ファイルが1ギガバイトを超える場合は、複数のファイルが格納されることもあります。 これらのファイルの命名規則については65.1で説明します。

You can monitor disk space in three ways: using the SQL functions listed in <xref linkend="functions-admin-dbsize"/>, using the <xref linkend="oid2name"/> module, or 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. 《機械翻訳》ディスクスペースの監視は、次の3つの方法で行えます。 表 9.100にあるSQL関数を使用する方法と oid2nameモジュールを使用する方法、およびシステムカタログを手動で調べる方法です。 SQL関数を使用する方法が、一般的に一番簡単な方法です。 本セクションの残りの部分で、システムカタログを調査することによりこの方法を示します。

Using <application>psql</application> on a recently vacuumed or analyzed database, you can issue queries to see the disk usage of any table: 《機械翻訳》最近バキュームされたか、あるいは分析されたデータベースでpsqlを使用すると、任意のテーブルのディスク使用状況を調べるための問い合わせを発行できます。

SELECT pg_relation_filepath(oid), relpages FROM pg_class WHERE relname = 'customer';

 pg_relation_filepath | relpages
----------------------+----------
 base/16384/16806     |       60
(1 row)

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 is of interest if you want to examine the table's disk file directly. 《機械翻訳》1ページは通常8キロバイトです (relpagesVACUUMANALYZE、さらにCREATE INDEXといったいくつかのDDLによってのみ更新されることに注意してください)。 もしテーブルのディスクファイルを直接調べるときは、ファイルのパス名称に注目して下さい。

To show the space used by <acronym>TOAST</acronym> tables, use a query like the following: 《機械翻訳》TOASTテーブルが使用しているスペースを表示するには、以下のようなクエリを使用します。

SELECT relname, relpages
FROM pg_class,
     (SELECT reltoastrelid
      FROM pg_class
      WHERE relname = 'customer') AS ss
WHERE oid = ss.reltoastrelid OR
      oid = (SELECT indexrelid
             FROM pg_index
             WHERE indrelid = ss.reltoastrelid)
ORDER BY relname;

       relname        | relpages
----------------------+----------
 pg_toast_16806       |        0
 pg_toast_16806_index |        1

You can easily display index sizes, too: 《機械翻訳》インデックスサイズも簡単に表示できます。

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_index |       26

It is easy to find your largest tables and indexes using this information: 《機械翻訳》この情報を使用すると、最大のテーブルとインデックスを簡単に見つけることができます。

SELECT relname, relpages
FROM pg_class
ORDER BY relpages DESC;

       relname        | relpages
----------------------+----------
 bigtable             |     3290
 customer             |     3144

27.6.2. Disk Full Failure #

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. 《機械翻訳》データベース管理者の最も重要なディスク監視作業は、ディスクが容量不足になっていないことを確認することです。 容量不足となったディスクにより、データが破壊されることはありません。 しかし、データ破壊が起こりやすくなる可能性があります。 もしWALファイルを持つディスクが一杯になった場合は、データベースサーバはパニックを起こし結果的にシャットダウンします。

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. 《機械翻訳》他のデータを削除しても、ディスクに空き容量を用意できない場合、 テーブル空間を使用することによって、データベースファイルのいくつかを 他のファイルシステムに移動させることができます。 詳細は 22.6を参照してください。

ヒント

Some file systems perform badly when they are almost full, so do not wait until the disk is completely full to take action. 《機械翻訳》一部のファイルシステムは、容量がほぼ一杯になっている場合にパフォーマンスが悪くなります。 ですから、ディスクがほぼ一杯になる前に余裕をもって対策を取ってください。

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. 《機械翻訳》システムでユーザ単位のディスククォータをサポートしている場合、当然ながらデータベースもサーバを実行するユーザに割り当てられたクォータに従います。 クォータを超えた場合、ディスク容量が完全になくなった時と同じ悪影響が発生します。