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

Date de la dernière mise à jour : 15/10/2020

J'ai une utilisation élevée ou complète du disque sur Amazon Redshift. Comment résoudre les problèmes qui entraînent 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 la distribution et l'inclinaison des lignes peuvent avoir un impact sur l'inclinaison du stockage et sur l'ensemble de lignes intermédiaire lorsqu'une requête est en cours d'exécution. Pour plus d'informations sur les clés de distribution et les clés de tri, consultez le Guide de conception de table avancé d'Amazon Redshift Engineering : préambule, conditions préalables et hiérarchisation.

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 une mémoire excessive, entraînant un débordement du disque. Pour plus d'informations, consultez Choix des clés de tri.

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

Traitement des requêtes

Vérifiez toute mémoire allouée à une requête. Pendant le traitement d'une requête, les résultats intermédiaires de la 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 sans codage de colonne pour les tables temporaires. Mais si vous utilisez la syntaxe SELECT...INTO, utilisez une instruction CREATE. Pour plus d'informations, consultez Les 10 meilleures techniques d'ajustement des performances pour Amazon Redshift , et suivez les instructions sous Conseil N° 6 : résoudre le problème d'utilisation inefficace des tables temporaires.

Si la mémoire allouée à votre requête est insuffisante, vous pouvez voir une étape dans SVL_QUERY_SUMMARYis_diskbased affiche la valeur « vrai ». 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 des requêtes WLM pour contrer les lourdes charges de traitement et pour identifier les requêtes intensives d'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, vérifiez 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 globale de stockage. 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 nettoyées. Une façon de maintenir l'intégrité de votre base de données consiste à identifier les statistiques manquantes ou obsolètes. Cela empêche Amazon Redshift d'analyser les lignes de table inutiles et aide également à optimiser le traitement de vos 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, donc un pic d'utilisation du disque est 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;

Produits cartésiens avec jointures croisées

Utilisez le plan 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 en boucle imbriquées, qui prennent 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 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 Pourquoi une table dans un 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 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 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, suffisamment de blocs 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 des 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;

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?