Comment résoudre les problèmes d'utilisation élevée ou complète du disque avec Amazon Redshift ?

Date de la dernière mise à jour : 27/03/2020

J'ai une utilisation élevée ou complète du disque sur Amazon Redshift. Comment puis-je résoudre les problèmes qui provoquent une utilisation élevée du disque ?

Résolution

Les erreurs d'utilisation élevée du disque peuvent dépendre de plusieurs facteurs, notamment :

  • Clé de distribution et de tri
  • Traitement des requêtes
  • Tables avec colonnes VARCHAR(MAX)
  • Compression élevée des colonnes
  • Opérations de maintenance
  • Produits cartésiens avec jointures croisées
  • Taille de table minimale
  • Blocs désactivés
  • Copie d'un fichier volumineux

Clé de distribution et de tri

Vérifiez le style de distribution, la clé de distribution et la sélection de clé de tri de la table. Un nœud de disque complet peut être causé par des tables ayant une asymétrie de distribution où plus de données se trouvent dans un nœud que les autres. Si vous avez des tables avec des styles de distribution asymétriques, remplacez le style de distribution par une distribution plus uniforme. Notez que l'asymétrie de la distribution et des lignes peut avoir un impact sur l'asymétrie du stockage et le jeu de lignes intermédiaires lors de l'exécution des requêtes. Pour plus d'informations sur les clés de distribution et les clés de tri, consultez Amazon Redshift Engineering's Advanced Table Design Playbook: Preamble, Prerequisites, and Prioritization (Playbook de conception de table avancée d'ingénierie Amazon Redshift : préambule, conditions préalables et priorisation).

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

select distkey, count(*) from public.distribution_skew group by distkey having count(*) > 1 order by 2 desc;

Remarque : pour éviter une étape de tri, utilisez les colonnes SORT KEY dans votre clause ORDER BY. Une étape de tri peut utiliser beaucoup de mémoire, ce qui entraîne un déversement de disque. Pour plus d'informations, consultez Choisir les clés de tri.

Pour voir comment les blocs de base de données d'une clé de distribution sont mappés à un cluster, utilisez l'utilitaire table_inspector.sql Amazon Redshift.

Traitement des requêtes

Vérifiez la mémoire allouée à une requête. Pendant le traitement d'une requête, les résultats intermédiaires de requête peuvent être stockés dans des blocs temporaires. S'il n'y a pas suffisamment de mémoire libre, les tables provoquent alors un déversement de disque. Les ensembles de résultats intermédiaires ne sont pas compressés, ce qui affecte l'espace disque disponible. Pour plus d'informations, consultez 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. Mais si vous utilisez la syntaxe SELECT...INTO, utilisez une instruction CREATE. Pour plus d'informations, consultez Top 10 Performance Tuning Techniques for Amazon Redshift (Les 10 meilleures techniques d'ajustement des performances pour Amazon Redshift), et suivez les instructions sous Tip #6: Address the inefficient use of temporary tables (Conseil 6 : résoudre le problème d'utilisation inefficace des tables temporaires).

Si une mémoire insuffisante est allouée à votre requête, il est possible de rencontrer une étape dans SVL_QUERY_SUMMARY ayant un champ is_diskbased indiquant la valeur « true ». Pour résoudre ce problème, augmentez le nombre d'emplacements de requête pour allouer plus de mémoire à la requête. Pour plus d'informations sur la façon d'augmenter temporairement les emplacements d'une requête, consultez wlm_query_slot_count ou Ajuster votre WLM pour exécuter des charges de travail mixtes. Vous pouvez également utiliser les règles de surveillance de requête WLM pour contrer les lourdes charges de traitement et pour identifier les requêtes gourmandes en E/S.

Tables avec colonnes VARCHAR(MAX)

Vérifiez les colonnes VARCHAR ou CHARACTER VARYING pour les espaces de fin qui peuvent être omis lorsque les données sont stockées sur le disque. Pendant le traitement des requêtes, les espaces de fin peuvent occuper toute la longueur en mémoire (la valeur maximale pour VARCHAR est 65535). Une bonne pratique consiste à utiliser la plus petite taille de colonne possible.

Pour générer une liste de tables avec des largeurs de colonnes 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;

Pour identifier et afficher les largeurs réelles des colonnes de la table VARCHAR large, exécutez la requête suivante :

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

Pour plus d'informations sur la conception de tables, consultez les bonnes pratiques Amazon Redshift pour la conception de tables.

Compression élevée des colonnes

Encodez toutes les colonnes (sauf la clé de tri) à l'aide de la COMPRESSION D'ANALYSE ou de l'utilitaire d'encodage de colonnes Amazon Redshift pour un encodage optimal des colonnes. Amazon Redshift fournit un encodage de colonne, ce qui peut augmenter les performances de lecture tout en réduisant la consommation de stockage globale. Une bonne pratique consiste à utiliser la fonction de compression du système.

Opérations de maintenance

Assurez-vous que les tables de base de données de votre base de données Amazon Redshift sont régulièrement analysées et vidées. Un moyen de maintenir l'état de votre base de données consiste à identifier les statistiques manquantes ou obsolètes. Cela évite à Amazon Redshift d'analyser toutes les lignes de table inutiles et permet également d'optimiser votre plan d'exécution des requêtes.

Remarque : les opérations de maintenance telles que VACUUM et DEEP COPY utilisent un espace de stockage temporaire pour leurs opérations de tri et un pic d'utilisation du disque est alors attendu.

Par exemple, la requête suivante vous aide à identifier les statistiques obsolètes dans Amazon Redshift :

SELECT * FROM svv_table_info WHERE stats_off > 10 ORDER BY size DESC;

Pour plus d'informations, consultez l'utilitaire d'analyse et de vidage de schéma Amazon Redshift.

Produits cartésiens avec jointures croisées

Utilisez le plan d'exécution EXPLAIN de la requête pour rechercher des requêtes avec des produits cartésiens. Les produits cartésiens sont des jointures croisées qui ne sont pas liées et qui peuvent produire un nombre accru de blocs. Ces jointures croisées peuvent entraîner une utilisation plus élevée 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, les jointures produisent un produit cartésien de deux tables. Chaque ligne d'une table est ensuite jointe à chaque ligne de l'autre table.

Les jointures croisées peuvent également être exécutées en tant que jointures de boucle imbriquées, ce qui prend le plus de temps à traiter. Les jointures de boucle imbriquées entraînent des pics d'utilisation globale du disque. Pour plus d'informations, consultez Identification des requêtes avec des boucles imbriquées.

Taille de table minimale

La même table peut avoir des tailles différentes dans différents clusters. La taille de table minimale est ensuite déterminée par le nombre de colonnes et si la table a une fonction SORTKEY et le nombre de tranches renseignés. Si vous avez récemment redimensionné un cluster Amazon Redshift, vous pouvez constater une modification de votre stockage sur disque global. Cela est dû à la modification du nombre de tranches. Amazon Redshift compte également les segments de table utilisés par chaque table. Pour plus d'informations, consultez la section Pourquoi une table d'un cluster Amazon Redshift utilise-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 vers une table Amazon Redshift se produit et qu'une lecture simultanée est effectuée. Amazon Redshift conserve les blocs avant l'opération d'écriture pour assurer la cohérence de l'opération de lecture simultanée. Les blocs Amazon Redshift ne peuvent pas être modifiés. Chaque action Insert (Insérer), Update (Mettre à jour) ou Delete (Supprimer) crée un nouvel ensemble de blocs, marquant les anciens blocs comme désactivés.

Parfois, les éléments désactivés ne parviennent pas à s'effacer à l'étape de validation en raison de transactions de table de longue durée. Les éléments désactivés n'arrivent pas à s'effacer parfois lorsqu'un trop grand nombre de charges ETL s'exécutent en même temps. Étant donné qu'Amazon Redshift surveille la base de données depuis le début de la transaction, 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, suffisamment d'éléments désactivés peuvent s'accumuler pour entraîner une erreur de disque plein.

Vous pouvez également forcer Amazon Redshift à effectuer l'analyse concernant les blocs désactivés en exécutant une commande de validation.

Si des requêtes de longue durée sont actives, mettez fin aux requêtes (et libérez tous les blocs suivants) à l'aide de la commande commit :

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

Pour confirmer les blocs désactivés, exécutez la requête suivante :

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;

Copie d'un fichier volumineux

Au cours d'une opération COPY, vous pouvez recevoir une erreur Disk Full (Disque plein) même s'il y a suffisamment de stockage disponible. Cette erreur se produit si l'opération de tri se déverse sur le disque, ce qui crée des blocs temporaires.

Si vous rencontrez un message d'erreur Disk Full, vérifiez la table STL_DISK_FULL_DIAG :

select '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,node_num,query_id,temp_blocks from pg_catalog.stl_disk_full_diag;

Pour plus de bonnes pratiques, consultez Bonnes pratiques Amazon Redshift pour le chargement de données.

Résolution de problèmes supplémentaires

Vérifiez le pourcentage d'espace disque sous l'onglet Performance de la console Amazon Redshift. Pour chaque nœud de cluster, Amazon Redshift fournit un espace disque supplémentaire, qui est supérieur à la capacité nominale du disque.

Si vous remarquez un pic soudain d'utilisation, utilisez STL_QUERY pour identifier les activités et les tâches qui sont en cours d'exécution :

select * from stl_query where starttime between '2018-01-01 00:30:00' and '2018-01-01 00:40:00';

Remarque : mettez à jour les valeurs avec l'heure à laquelle le pic s'est produit.

Pour identifier les 20 premières requêtes de déversement de disque, exécutez la requête suivante :

select A.userid, A.query, blocks_to_disk, trim(B.querytxt) text from stl_query_metrics A, stl_query B where A.query = B.query and segment=-1 and step = -1 and max_blocks_to_disk > 0 order by 3 desc limit 20;

Pour déterminer si vos requêtes écrivent correctement sur un disque, exécutez la requête suivante :

SELECT q.query, trim(q.cat_text)
FROM (
SELECT query,
replace( listagg(text,' ') WITHIN GROUP (ORDER BY sequence), '\\n', ' ') AS cat_text
FROM stl_querytext
WHERE userid>1
GROUP BY query) q
JOIN (
SELECT distinct query
FROM svl_query_summary
WHERE is_diskbased='t' AND (LABEL ILIKE 'hash%' OR LABEL ILIKE 'sort%' OR LABEL ILIKE 'aggr%' OR LABEL ILIKE 'save%' OR LABEL ILIKE 'window%' OR LABEL ILIKE 'unique%')
AND userid > 1) qs
ON qs.query = q.query;

Cette page vous a-t-elle été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d’aide ?