Comment résoudre les problèmes liés à une utilisation élevée du disque ou une utilisation du disque complet avec Amazon Redshift ?

Résolution

Pour résoudre les problèmes d'utilisation élevée du disque ou d'utilisation d’un disque plein pour Amazon Redshift, suivez ces étapes de dépannage.

Clé de distribution et de tri

Examinez la sélection du style de distribution, de la clé de distribution et de la clé de tri de la table. Les tables présentant une asymétrie de distribution peuvent provoquer un nœud de disque plein. Si vos tables présentent des styles de distribution asymétriques, modifiez le style de distribution pour une distribution plus uniforme. L’asymétrie de distribution et de ligne peut affecter l'asymétrie du stockage et le jeu de lignes intermédiaire lors de l'exécution d'une requête.

Pour obtenir la cardinalité de votre clé de distribution, exécutez la requête suivante :

SELECT <distkey column>, COUNT(*)
 FROM <schema name>.<table with distribution skew>
 GROUP BY <distkey column>
 HAVING COUNT(*) > 1
 ORDER BY 2 DESC;

Remarque : Remplacez la colonne distkey, le nom du schéma et la table par une asymétrie de distribution avec les variables de votre table.

Pour éviter une étape de tri, utilisez les colonnes SORT KEY dans votre clause ORDER BY. Une étape de tri peut utiliser une quantité de mémoire excessive et provoquer un débordement du disque. Pour plus d’informations, consultez la section Clés de tri.

Dans le jeu de résultats filtré, choisissez une colonne à cardinalité élevée pour afficher la distribution de ses données. Pour plus d'informations, consultez la section Choisir le meilleur style de distribution.

Traitement des requêtes

Vérifiez toute mémoire de requête allouée. Les résultats de requêtes intermédiaires peuvent être stockés dans des blocs temporaires lors du traitement des requêtes. Si la quantité de mémoire disponible est insuffisante, les tables provoquent un débordement du disque. Les jeux de résultats intermédiaires ne sont pas compressés, ce qui affecte l'espace disque disponible. Pour plus d'informations, consultez la section Mémoire insuffisante allouée à la requête.

Amazon Redshift utilise par défaut une structure de table avec une distribution uniforme et aucun encodage de colonne pour les tables temporaires. Si vous utilisez la syntaxe SELECT...INTO, utilisez une instruction CREATE. Pour plus d'informations, consultez les 6 meilleures techniques d’optimisation des performances pour Amazon Redshift.

Si la mémoire allouée à votre requête est insuffisante, vous pouvez voir apparaître une étape dans SVL_QUERY_SUMMARY où is_diskbased affiche la valeur vrai. La requête suivante identifie les 20 principales requêtes de débordement du disque pendant une période donnée :

SELECT q.userid, q.query, q.starttime, q.endtime, m.query_temp_blocks_to_disk, btrim(querytxt)  
 FROM stl_query q JOIN SVL_QUERY_METRICS_SUMMARY m ON m.query = q.query
 WHERE m.query_temp_blocks_to_disk > 0
   AND starttime BETWEEN '2025-01-01 00:00:00' AND '2025-01-02 00:00:00'
 ORDER BY m.query_temp_blocks_to_disk DESC
 LIMIT 20;

Pour résoudre ce problème, augmentez le nombre d'emplacements de requête afin d'allouer plus de mémoire à la requête.

Si vous constatez un pic d'utilisation soudain, exécutez la requête suivante pour identifier les 20 principales requêtes de débordement du disque :

SELECT a.userid, a.query, a.blocks_to_disk, trim(b.text) as text
 FROM stv_query_metrics a, stv_inflight b
 WHERE a.query = b.query
   AND a.segment = -1
   AND a.step_type = -1
   AND a.max_blocks_to_disk > 0
 ORDER BY 3 DESC
 LIMIT 20;

Dans la sortie, recherchez la valeur de colonne blocks_to_disk pour identifier les débordements de disque. Mettez fin aux requêtes trop volumineuses, puis allouez plus de mémoire aux requêtes avant de les exécuter à nouveau.

Vous pouvez également utiliser les règles de surveillance des requêtes WLM pour faire face à de lourdes charges de processus et pour identifier les requêtes gourmandes en E/S.

Tables avec colonnes VARCHAR (MAX)

Vérifiez que les colonnes VARCHAR ou CHARACTER VARYING ne contiennent pas d’espaces de fin susceptibles d’être omis lorsque des données sont stockées sur le disque. Lorsque les requêtes sont traitées, les espaces de fin peuvent occuper toute la longueur de la mémoire. La valeur maximale pour VARCHAR et CHARACTER VARIING est de 65 535 octets. Il est recommandé d'utiliser la plus petite taille de colonne possible.

Pour générer une liste de tables présentant des largeurs de colonne maximales, exécutez la requête suivante :

SELECT database, schema || '.' || "table" AS "table", max_varchar
 FROM svv_table_info
 WHERE max_varchar > 150 ORDER BY 2;

Exécutez la requête suivante pour identifier et afficher la largeur réelle des larges colonnes de la table VARCHAR :

SELECT max(octet_length (rtrim(column_name))) FROM table_name;

Dans le résultat de cette requête, confirmez que la longueur correspond à votre cas d'utilisation. Si la longueur des colonnes est maximale et dépasse vos besoins, ajustez leur longueur à la taille minimale requise.

Pour plus d'informations, consultez la section Bonnes pratiques d'Amazon Redshift relatives à la conception de tables.

Compression de colonne élevée

Pour encoder toutes les colonnes à l'exception de la clé de tri, utilisez la fonction ANALYZE COMPRESSION ou l'optimisation automatique de table. Il est recommandé d'utiliser l’encodage des colonne.

Opérations de maintenance

Veillez à analyser et à vider régulièrement les tables de base de données dans votre base de données Amazon Redshift. Identifiez toutes les requêtes exécutées sur des tables dont les statistiques sont manquantes. Ensuite, empêchez les requêtes de s'exécuter sur des tables dont les statistiques sont manquantes afin qu'Amazon Redshift n'analyse pas les lignes de table inutiles.

Remarque : Les opérations de maintenance telles que VACUUM et DEEP COPY utilisent de l'espace de stockage temporaire pour leurs opérations de tri et peuvent provoquer un pic d'utilisation du disque.

Par exemple, la requête suivante identifie des statistiques obsolètes dans Amazon Redshift :

SELECT table_id, database, schema, "table", stats_off, size
 FROM svv_table_info
 WHERE stats_off > 10
 ORDER BY size DESC;

En outre, utilisez la commande ANALYZE pour afficher et analyser les statistiques de table.

Produits cartésiens avec jointures croisées

Utilisez le plan EXPLAIN de la requête pour rechercher des requêtes contenant des produits cartésiens. Les produits cartésiens sont des jointures croisées qui ne sont pas liées et qui peuvent augmenter le nombre de blocs. Ces jointures croisées peuvent entraîner une augmentation de l'utilisation de la mémoire et un plus grand nombre de tables déversées sur le disque. Si les jointures croisées ne partagent pas de condition JOIN, elles produisent un produit cartésien de deux tables. Chaque ligne d'une table est jointe à chaque ligne de l'autre table.

Les jointures croisées peuvent également s'exécuter sous forme de jointures en boucle imbriquées et entraîner de longs délais de traitement. Les jointures en boucle imbriquées entraînent des pics d'utilisation globale du disque. Pour plus d'informations, consultez la section Identification des requêtes à l'aide de boucles imbriquées.

Taille de table minimale

Les tables individuelles peuvent avoir des tailles différentes selon les clusters. La taille de table minimale est déterminée par le nombre de colonnes et si la table a une fonction SORTKEY ainsi que par le nombre de tranches renseignées. Si vous avez récemment redimensionné un cluster Amazon Redshift, vous pourriez constater une modification de l'espace de stockage global de votre disque due à la modification des tranches. Amazon Redshift compte également les segments de table utilisés par chaque table. Pour plus d'informations, reportez-vous à la section Pourquoi une table dans mon cluster Amazon Redshift consomme-t-elle plus ou moins d'espace de stockage sur disque que prévu ?

Blocs désactivés

Les blocs désactivés sont générés lorsqu'une transaction WRITE dans une table Amazon Redshift se produit et qu'il existe une opération de lecture simultanée. Amazon Redshift conserve les blocs avant l'opération d'écriture afin de garantir la cohérence d'une opération de lecture simultanée. Vous ne pouvez pas modifier les blocs Amazon Redshift. Chaque action d'insertion, de mise à jour ou de suppression crée un nouvel ensemble de blocs et marque les anciens blocs comme désactivés.

Parfois, les blocs désactivés ne parviennent pas à s'effacer à l'étape de validation en raison de transactions de table de longue durée. Les blocs désactivés peuvent également ne pas s'effacer lorsqu'il y a trop de charges ETL en cours d'exécution en même temps. Étant donné qu'Amazon Redshift surveille la base de données à partir du moment où la transaction démarre, toute table écrite dans la base de données conserve également les blocs désactivés. Si des transactions de table de longue durée se produisent régulièrement et sur plusieurs charges, un nombre suffisant de blocs désactivés peut s'accumuler pour entraîner une erreur « Disk Full » (Disque plein).

Si des requêtes de longue durée sont actives, exécutez la commande commit pour mettre fin aux requêtes et libérer tous les blocs suivants :

begin;
create table a (id int);
insert into a values(1);
commit;
drop table a;

Exécutez la requête suivante pour confirmer les blocs désactivés :

SELECT trim(name) as tablename, count(case when tombstone > 0 then 1 else null end) as tombstones
 FROM svv_diskusage
 GROUP BY 1
 HAVING count(case when tombstone > 0 then 1 else null end) > 0
 ORDER BY 2 DESC;

Copier un fichier volumineux

Une opération COPY peut recevoir une erreur « Disk Full », même si l'espace de stockage disponible est suffisant. Cette erreur se produit si l'opération de tri déborde sur le disque et crée des blocs temporaires.

Si vous rencontrez une erreur « Disk Full », consultez la table STL_DISK_FULL_DIAG. Vérifier les blocages temporaires et l'ID de requête à l'origine de l'erreur :

SELECT
  '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,
  node_num,
  query_id,
  temp_blocks
 FROM stl_disk_full_diag;

Pour plus d'informations, consultez la section Bonnes pratiques d'Amazon Redshift relatives au chargement de données.

Blocs de requêtes d’unité de partage des données sur les clusters de consommateurs

Lorsqu'une requête d’unité de partage des données s'exécute sur le cluster de consommateurs, les blocs de données associés à la requête sont comptabilisés sur la base des métriques PercentageDiskSpaceUsed. Ces blocs de données sont supprimés des métriques PercentageDiskSpaceUsed en raison d'un redémarrage du cluster et d'autres facteurs. Aucune autre action n'est requise pour ce comportement attendu.

Vérifier l'espace disque

Vérifiez le pourcentage d'espace disque sous l'onglet Performances de la console Amazon Redshift.

Informations connexes

Performances d'Amazon Redshift