Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je gère une base volumineuse (300 Go) pour laquelle j'ai eu une requête assez importante avec tri par ORDER BY, requête qui m'a fait planter le SGBD après avoir saturé l'espace disque où est situé le répertoire pgsql_tmp.
Effectivement plusieurs dizaines de Go ont été écrits sous ce répertoire jusqu'à saturation. Lorsque j'ai relancé la base, tout a été effacé et c'est reparti. Mais la requête a été relancée plus tard et même souci.
Question : comment gérer au mieux pour que cela ne se reproduise plus?
Pour information, la variable work_mem est à 50 Mo, mais je ne compte pas l'augmenter.
Sur quoi peut-on jouer pour éviter ces désagréments?
Merci d'avance
Y.
Hors ligne
Si vous avez besoin d'autant d'espace de tri, c'est soit que c'est réellement nécessaire (un tri vraiment énorme), soit que vous avez un produit cartésien ou quelque chose de ce genre dans la requête. Vérifiez déjà ce point.
Si vous avez réellement besoin de cet espace, vous pouvez créer un nouveau tablespace, et le déclarer comme tablespace temporaire (paramètre temp_tablespaces dans postgresql.conf). En le mettant dans un système de fichiers dédiés, ça vous évitera déjà que ça fasse potentiellement planter la base. Et ça vous permettra d'allouer un espace temporaire d'une taille suffisante.
Marc.
Hors ligne
Une requête qui fait un tri qui génère plusieurs Go de données temporaires ? peu importe si vous comptez augmenter work_mem ou pas, il faudrait tellement de mémoire que ce n'est pas pensable. Sans parler du temps d'exécution de la requête... Bref, je pencherai plutôt pour un produit cartésien dans la requête.
Guillaume.
Hors ligne
Effectivement, je confirme qu'il y avait bien un produit cartésien (requête sur 4 fois la même table) suivi d'un ORDER BY ; je vais donc faire un système de fichiers dédié ; ceci dit, je ne peux pas empêcher certains utilisateurs de faire ce genre de requête...
Que va-t-il se passer lorsque ce système de fichiers dédié sera saturé?
Merci
Hors ligne
Les requêtes qui voudront y allouer davantage de place seront annulées.
Si vous n'avez pas confiance en vos utilisateurs, qui peuvent lancer n'importe quelle requête, vous pouvez toujours positionner un statement_timeout à une valeur raisonnable, afin d'arrêter les requêtes anormalement longues.
Marc.
Hors ligne
Si je configure statement_timeout dans postgresql.conf, cela va affecter toutes les sessions ; d'ailleurs il est déconseillé de le faire dans la doc Postgresql en ligne.
Est-ce que je peux créer un trigger sur ouverture de session afin de configurer cette variable pour un seul utilisateur ?
Hors ligne
Non, les triggers ne sont définissables que sur les instructions de données (INSERT, UPDATE, DELETE, COPY et TRUNCATE).
Guillaume.
Hors ligne
Mais il suffit de faire :
ALTER USER TOTO set statement_timeout TO xxxx;
Marc.
Hors ligne
Effectivement, je confirme qu'il y avait bien un produit cartésien (requête sur 4 fois la même table) suivi d'un ORDER BY ; je vais donc faire un système de fichiers dédié ; ceci dit, je ne peux pas empêcher certains utilisateurs de faire ce genre de requête...i
Si en leur imposant de faire des jointures avec des JOIN et non dans la clause WHERE... Cela empêche ce type d'erreur est cette syntaxe est la norme depuis la version 1992, soit 19 ans !!!
A lire : http://sqlpro.developpez.com/cours/sqla … res/#LII-B
Je m'étonne encore qu'il y ai des développeurs faisant leur jointures dans la clause WHERE !
Quel manque de formation....
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Moi je oréfère le faire dans la clause WHERE. Chacun ses goûts.
Guillaume.
Hors ligne
Pages : 1
