Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Gestion des fichiers temporaires avec PostgreSQL Dans PostgreSQL, une requête complexe peut exécuter simultanément plusieurs opérations de tri ou de hachage, chacune utilisant la mémoire de l’instance pour stocker les résultats jusqu’à la valeur spécifiée par le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Ils sont écrits sur le disque pour terminer l’exécution de la requête. Par la suite, ces fichiers sont automatiquement supprimés une fois la requête terminée. Dans RDS pour PostgreSQL, ces fichiers sont stockés dans Amazon EBS sur le volume de données. Pour plus d’informations, consultez [Stockage d’instance de base de données Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). Vous pouvez surveiller la `FreeStorageSpace` métrique publiée dans CloudWatch pour vous assurer que votre instance de base de données dispose de suffisamment d'espace de stockage disponible. Pour plus d’informations, consultez [https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm](https://repost.aws/knowledge-center/storage-full-rds-cloudwatch-alarm). Nous recommandons d’utiliser des instances Lectures optimisées pour Amazon RDS pour les charges de travail impliquant plusieurs requêtes simultanées qui augmentent l’utilisation de fichiers temporaires. Ces d'instances utilisent un stockage local au niveau des blocs basé sur un disque SSD (Non-Volatile Memory Express) pour placer les fichiers temporaires. NVMe Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour RDS pour PostgreSQL avec Lectures optimisées pour Amazon RDS](USER_PostgreSQL.optimizedreads.md). Vous pouvez utiliser les paramètres et fonctions suivants pour gérer les fichiers temporaires dans votre instance. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** : ce paramètre annule toute requête dépassant la taille des fichiers temp\$1files en Ko. Cette limite empêche toute requête de s’exécuter indéfiniment et de consommer de l’espace disque avec des fichiers temporaires. Vous pouvez estimer la valeur à l’aide des résultats du paramètre `log_temp_files`. Nous vous recommandons d’examiner le comportement de la charge de travail et de définir la limite en fonction de l’estimation. L’exemple suivant présente la manière dont une requête est annulée lorsqu’elle dépasse la limite. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** : ce paramètre envoie des messages au fichier postgresql.log lorsque les fichiers temporaires d’une session sont supprimés. Ce paramètre produit des journaux lorsqu’une requête est terminée avec succès. Par conséquent, cela peut ne pas aider à résoudre les requêtes actives et de longue durée. L’exemple suivant montre que lorsque la requête aboutit, les entrées sont journalisées dans le fichier postgresql.log pendant que les fichiers temporaires sont nettoyés. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** : cette fonction disponible auprès de RDS pour PostgreSQL versions 13 et ultérieures offre une visibilité sur l’utilisation actuelle des fichiers temporaires. La requête terminée n’apparaît pas dans les résultats de la fonction. Dans l’exemple suivant, vous pouvez visualiser les résultats de cette fonction. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` Le nom du fichier inclut l’ID de traitement (PID) de la session qui a généré le fichier temporaire. Une requête plus avancée, comme dans l’exemple suivant, effectue la somme des fichiers temporaires pour chaque PID. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** : si vous activez le paramètre pg\$1stat\$1statements, vous pouvez consulter l’utilisation moyenne des fichiers temporaires par appel. Vous pouvez identifier le query\$1id de la requête et l’utiliser pour examiner l’utilisation des fichiers temporaires, comme indiqué dans l’exemple suivant. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** : dans le tableau de bord Performance Insights, vous pouvez consulter l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. Vous pouvez ensuite voir la moyenne de ces deux métriques et voir comment elles correspondent à la charge de travail des requêtes. La vue de Performance Insights n’affiche pas spécifiquement les requêtes qui génèrent les fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête indiquée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes. Pour plus d’informations sur l’analyse des métriques et des requêtes à l’aide de Performance Insights, consultez [Analyse des métriques à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.UsingDashboard.md). Pour consulter un exemple d’utilisation des fichiers temporaires avec Performance Insights, consultez [Affichage de l’utilisation des fichiers temporaires avec Performance Insights](PostgreSQL.ManagingTempFiles.Example.md) # Affichage de l’utilisation des fichiers temporaires avec Performance Insights Vous pouvez consulter utiliser Performance Insights pour afficher l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. La vue indiquée dans Performance Insights ne montre pas les requêtes spécifiques qui génèrent des fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête affichée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes. 1. Dans le tableau de bord de Performance Insights, choisissez **Gérer les métriques**. 1. Choisissez **Métriques de base de données** et sélectionnez les métriques **temp\$1bytes** et **temp\$1files** comme indiqué dans l’image suivante. ![\[Métriques affichées dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_metrics.png) 1. Dans l’onglet **SQL maximum**, cliquez sur l’icône **Préférences**. 1. Dans la fenêtre **Préférences**, activez les statistiques suivantes pour qu’elles apparaissent dans l’onglet **SQL maximum** et choisissez **Continuer**. + Nombre d’écritures temporaires/seconde + Nombre de lectures temporaires/seconde + Écritures/appels en bloc temporaires + Lectures/appels en bloc temporaires 1. Le fichier temporaire est décomposé lorsqu’il est associé à la requête affichée pour `pg_ls_tmpdir`, comme le montre l’exemple suivant. ![\[Requête qui affiche l’utilisation du fichier temporaire.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/rpg_mantempfiles_query.png) Les événements `IO:BufFileRead` et `IO:BufFileWrite` se produisent lorsque les requêtes les plus importantes de votre charge de travail créent souvent des fichiers temporaires. Vous pouvez utiliser l’analyse des performances pour identifier les requêtes les plus importantes en attente sur `IO:BufFileRead` et `IO:BufFileWrite` en passant en revue Sessions actives en moyenne (AAS) dans les sections Charge de base de données et Principaux éléments SQL. ![\[IO : BufFileRead et IO : BufFileWrite dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/perfinsights_IOBufFile.png) Pour plus d’informations sur la façon d’analyser les requêtes les plus importantes et la charge par événement d’attente à l’aide de l’analyse des performances, consultez [Présentation de l'onglet Top SQL (Principaux éléments SQL)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Vous devez identifier et ajuster les requêtes qui entraînent une augmentation de l’utilisation des fichiers temporaires et des événements d’attente associés. Pour plus d'informations sur ces événements d'attente et les mesures correctives, voir [IO : BufFileRead et IO : BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/wait-event.iobuffile.html) . **Note** Le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) contrôle le moment où la mémoire de l’opération de tri est insuffisante et les résultats sont écrits dans des fichiers temporaires. Nous vous recommandons de ne pas modifier la valeur de ce paramètre au-delà de la valeur par défaut, car cela permettrait à chaque session de base de données de consommer davantage de mémoire. En outre, une session unique qui effectue des jointures et des tris complexes peut effectuer des opérations parallèles au cours desquelles chaque opération consomme de la mémoire. Il est recommandé de définir ce paramètre au niveau de la session à l’aide de la commande `SET work_mem` lorsque vous disposez d’un rapport volumineux comportant plusieurs jointures et tris. La modification n’est alors appliquée qu’à la session en cours et ne modifie pas la valeur de manière globale.