PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 25/10/2020 19:25:11

k20d
Membre

MAnque de place pour objets temporaires

Bonjour à tous,
J'ai installé récemment un PostgreSql 10 (je débute sur ce SGBD) sur un windows 2008 Server (fallait prendre ce qui était dispo).
Le but étant d'assurer pendant quelques années l'accès à des données issues d'une application qui va être arrêtée.
Après avoir chargé 1 an de données, j'ai voulu faire des requêtes de contrôle, ça plante sur l'une d'elle.

La requête qui pose problème fait appel à des agrégats, sur 2 mois elle passe, mais sur 1 an ça plante :

ERROR: ERREUR: n'a pas pu écrire le fichier temporaire de la jointure hâchée : No space left on device CONTEXT: processus parallèle
SQL state: 53100

J'ai créé un tablespace que j'ai défini comme étant celui par défaut pour ma base de données, il est défini sur un lecteur qui a 160Go de libre
Si je demande sa taille dans le gestionnaire de fichier, il m'indique 529Mo.

Je n'ai rien spécifié pour faire créer les objets temporaires dans un espace spécifique, donc si j'ai bien compris il crée les trucs temporaires sur le tablespace de la base, lequel a 160Go de libre !
En examinant plus loin, je me rend compte qu'il me manque un index et que ma requête entraîne un table scan pour une jointure.
Donc j'essaye de créer l'index manquant, mais là nouvelle erreur :

ERROR: ERREUR: n'a pas pu étendre le fichier « pg_tblspc/16394/PG_10_201707211/16396/18536 » : No space left on device HINT: Vérifiez l'espace disque disponible.
SQL state: 53100

J'ai essayé la requête suivante :
select datname, temp_files, temp_bytes
from pg_stat_database

Elle donne :
"postgres"    0    0
"template1"    0    0
"template0"    0    0
"kenobi"    486    466064825
"siec"    0    0

Si j'interprète cela correctement, le tablespace de ma base contient 486 fichiers temporaires pour plus de 400 Mo.
Même après redémarrage de PostgreSql j'ai toujours le même résultat.
Les 529 Mo indiqués par windows ne pourraient pas contenir les données chargées + 400 Mo de fichier temporaires, il y a déjà une incohérence à ce niveau, ou alors les fichiers temporaires son ailleurs ?

J'ai essayé de modifier un paramètre, j'ai enlevé la mise en commentaire :   temp_file_limit = -1
Ca n'a rien changé au problème.

Sous pgAdmin 4 j'ai essayé de lancer un vacuum ordinaire (aucune des options cochées : full, freeze, analyse), il passe en 15s
Si je tente un full ça plante en 1s, après avoir pu passer des petites tables de référence, il plante sur la première table importante à laquelle il s'attaque :

INFO: exécution du VACUUM sur "public.t_clients"
ERREUR: n'a pas pu étendre le fichier "pg_tblspc/16394/PG_10_201707211/16396/18558" : No space left on device
HINT: Vérifiez l'espace disque disponible

Par contre le répertoire indiqué est sur C:    C:\Program Files\PostgreSQL\10\data\pg_tblspc
Sur C: il y a 27 Go de libre.

Y a-t-il des paramètres à contrôler ?, que me conseiller vous ?

Hors ligne

#2 26/10/2020 05:52:25

rjuju
Administrateur

Re : MAnque de place pour objets temporaires

Bonjour,


Effectivement, les objets temporaires devraient également être stockés sur le tablespace par défaut définit sur votre base.  Comment avez-vous configurés cela ?


J'ai essayé la requête suivante :
select datname, temp_files, temp_bytes
from pg_stat_database

Elle donne :
"postgres"    0    0
"template1"    0    0
"template0"    0    0
"kenobi"    486    466064825
"siec"    0    0

Si j'interprète cela correctement, le tablespace de ma base contient 486 fichiers temporaires pour plus de 400 Mo.

Non, cela veut dire qu'il y a eu 486 fichiers générés, pour environ 444 Mo de données, depuis la dernière réinitialisation des statistiques.  Si aucune requête n'est en cours d'exécution, ces fichiers ont alors été supprimés.


Si je tente un full ça plante en 1s, après avoir pu passer des petites tables de référence, il plante sur la première table importante à laquelle il s'attaque :

INFO: exécution du VACUUM sur "public.t_clients"
ERREUR: n'a pas pu étendre le fichier "pg_tblspc/16394/PG_10_201707211/16396/18558" : No space left on device
HINT: Vérifiez l'espace disque disponible

Par contre le répertoire indiqué est sur C:    C:\Program Files\PostgreSQL\10\data\pg_tblspc
Sur C: il y a 27 Go de libre.

Le répertoire pg_tblspc/16394 devrait être un "junction" vers le disque que vous avez spécifié pour votre tablespace.  Pouvez-vous vérifier qu'il pointe bien vers le bon disque et répertoire ?


Sinon, un VACUUM FULL fonctionne en réécrivant entièrement chaque table ainsi que ses index, vous avez donc besoin d'avoir suffisamment d'espace pour stocker votre plus grosse table et tous ses index ainsi que sa nouvelle version (qui devrait logiquement être plus petite).

Hors ligne

#3 26/10/2020 15:51:59

k20d
Membre

Re : MAnque de place pour objets temporaires

Merci tes indications et conseils rjuju.

J'ai fait générer le script de création de la base j'obtiens cela :

CREATE DATABASE kenobi
    WITH
    OWNER = postgres
    ENCODING = 'UTF8'
    LC_COLLATE = 'French_France.1252'
    LC_CTYPE = 'French_France.1252'
    TABLESPACE = kenobi_space
    CONNECTION LIMIT = -1;

Pour le tablespace :

CREATE TABLESPACE kenobi_space
    OWNER postgres
    LOCATION 'I:\ArchiveKenobi\data_kenobi';

ALTER TABLESPACE kenobi_space
    OWNER TO postgres;

Si je fais un dir dans C:\Program Files\PostgreSQL\10\data\pg_tblspc, j'ai l'affichage suivant :

Répertoire de C:\Program Files\PostgreSQL\10\data\pg_tblspc
06/08/2020  10:39    <JONCTION>     16394 [\??\I:\ArchiveKenobi\data_kenobi]
16/10/2020  15:01    <JONCTION>     18418 [\??\I:\ArchiveSiec\data_siec]

Si je vais voir sur I:

I:\ArchiveKenobi\data_kenobi>dir
Le volume dans le lecteur I s'appelle Data
Le numéro de série du volume est 06B7-39B4
Répertoire de I:\ArchiveKenobi\data_kenobi

06/08/2020  10:39    <REP>          .
06/08/2020  10:39    <REP>          .
25/09/2020  14:21    <REP>          PG_10_201707211
               0 fichier(s)                0 octets
               3 Rép(s)  171 799 588 864 octets libres

Dans PG_10_201707211 j'ai :

Répertoire de I:\ArchiveKenobi\data_kenobi\PG_10_201707211
25/09/2020  14:21    <REP>          .
25/09/2020  14:21    <REP>          ..
26/10/2020  07:04    <REP>          16396
25/10/2020  17:32    <REP>          pgsql_tmp
               0 fichier(s)                0 octets
               4 Rép(s)  171 799 588 864 octets libres

Sous windows en demandant les propriétés de 16396 j'obtiens un volume de 529 Mo

Sous PgAdmin 4, quand je sélectionne kenobi_space et que je prends l'onglet "Dependants", il liste le contenu du tablespace, il y a la base kenobi, les tables, indexes et vues.
Ma base est bien là.

Pour la table sur laquelle le vaccum full a planté, pgAdmin indique :
    Table size :    58 MB
    Indexes size :    13 MB
Ca n'a vraiment rien d'énorme !

Pgsql_tmp est vide.

J'ai activé le paramètre :    log_temp_files = -1
Cela n'a rien résolu ...

J'ai paramétré "temp_buffers = 50MB", mais la façon dont est utilisée ce para n'est pas 100% claire pour moi, est ce suffisant ?

Hors ligne

#4 26/10/2020 22:38:16

gleu
Administrateur

Re : MAnque de place pour objets temporaires

Plusieurs choses:
* Que vous ne voyez rien dans pgsql_tmp n'est pas anormale. Les fichiers ne sont créés que lors de l'exécution d'une requête, ils sont supprimés dès la requête terminée (normalement ou après une erreur).
* log_temp_files=-1 ne trace aucune création de fichiers. Enlever le dièse sans changer la valeur ne fait qu'utiliser l'ancienne valeur. En configurant log_temp_files à 0 (et après rechargement de la configuration), tout fichier temporaire créé sera tracé.
* temp_buffers concerne les objets temporaires, donc rien à voir avec les fichiers temporaires de pgsql_tmp.


Guillaume.

Hors ligne

#5 27/10/2020 13:24:31

k20d
Membre

Re : MAnque de place pour objets temporaires

Bon j'ai finalement trouvé.
C'est simplement les administrateurs de la machine qui avaient mis un quota à 500 Mo par personne ...

Merci à rjuju et gleu, vos interventions n'ont pas été inutiles car vous m'avez tous les deux appris des trucs qui me seront utiles.

Cordialement, Didier

Hors ligne

Pied de page des forums