PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 17.1 » Administration du serveur » Superviser l'activité de la base de données » Surveiller l'utilisation du disque

27.6. Surveiller l'utilisation du disque #

Cette section discute de la surveillance de l'utilisation du disque sur un système de bases de données PostgreSQL.

27.6.1. Déterminer l'utilisation du disque #

Chaque table a un fichier disque primaire où la plupart des données est enregistrée. Si la table a des colonnes potentiellement volumineuses, un fichier TOAST, associé à la table, est utilisé pour enregistrer les valeurs trop volumineuses pour tenir confortablement dans le fichier principal (voir Section 65.2). Il existe un index sur la table TOAST. Il peut aussi y avoir des index sur la table de base. Chaque table et index sont enregistrés dans un fichier séparé sur disque -- potentiellement plus d'un fichier, si le fichier dépasse 1 Go. Les conventions de nommage de ces fichiers sont décrits dans Section 65.1.

Vous pouvez superviser l'espace disque de trois façons : en utilisant les fonctions SQL listées dans Tableau 9.100, en utilisant le module oid2name ou en inspectant manuellement les catalogues systèmes. Les fonctions SQL sont le moyen le plus simple à utiliser et sont de ce fait les plus fréquemment recommendées. Le reste de cette section montre comment le faire à partir d'une inspection des catalogues systèmes.

En utilisant psql sur une base récemment traitée par un VACUUM ou un ANALYZE, vous pouvez lancer la requête suivante pour voir l'utilisation disque d'une table :

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

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

Chaque bloc fait habituellement 8 Ko. (Pour rappel, relpages est seulement mis à jour par les commandes VACUUM, ANALYZE et quelques commandes DDL telles que CREATE INDEX.) Le chemin du fichier est intéressant si vous souhaitez examiner le fichier de la table directement sur le disque.

Pour afficher l'espace utilisé par les tables TOAST, utilisez la requête suivante :

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

Vous pouvez aisément afficher les tailles des index :

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

Il est facile de trouver vos tables et index les plus volumineux en utilisant cette requête :

SELECT relname, relpages
FROM pg_class
ORDER BY relpages DESC;

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

27.6.2. Échecs pour cause de disque plein #

La tâche la plus importante en ce qui concerne la supervision des disques pour un administrateur de base de données est de s'assurer que le disque ne devienne pas plein. Un disque plein ne causera pas de corrution de données mais empêchera toute activité utile. Si le disque contenant les fichiers WAL devient plein, le serveur entre en mode panique et un arrêt survient.

Si vous ne pouvez pas libérer de l'espace sur le disque en supprimant d'autres choses, vous pouvez déplacer certains fichiers de la base vers d'autres systèmes de fichier en utilisant des tablespaces. Voir Section 22.6 pour plus d'informations sur cela.

Astuce

Certains systèmes de fichiers sont contre-performants quand ils sont pratiquement plein, donc n'attendez pas que le disque soit plein pour entrer en action.

Si votre système supporte des quotas disque par utilisateur, alors la base de données sera naturellement sujette à tout quota placé sur l'utilisateur qui exécute le serveur. Atteindre le quota aura les mêmes mauvais effets qu'un disque complètement plein.