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

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. Les tables ayant une asymétrie de distribution où plus de données se trouvent dans un nœud que les autres peuvent être à l'origine d'un nœud de disque complet. 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 affecter l'inclinaison du stockage et 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ée 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 column>, COUNT(*) FROM <schema name>.<table with distribution skew> GROUP BY <distkey column> 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 Utilisation des clés de tri.

Dans le jeu de résultats filtré, choisissez une colonne avec une cardinalité élevée afin d'afficher sa distribution des données. Pour plus d'informations sur le style de distribution de votre table, consultez Choisir le meilleur style de distribution.

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. Cependant, si vous utilisez la syntaxe SELECT...INTO, utilisez une instruction CREATE. Pour plus d'informations, consultez le Top 10 des techniques de réglage des performances pour Amazon Redshift. Suivez les instructions reprises sous Conseil n° 6 : remédier à l'utilisation inefficace des tables temporaires.

Si la mémoire allouée à votre requête est insuffisante, vous pouvez voir une étape dans SVL_QUERY_SUMMARY où is_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;

Dans la sortie de cette requête, vérifiez si la longueur est appropriée à votre cas d'utilisation. Si les colonnes sont à la longueur maximale et dépassent vos besoins, ajustez leur longueur à la taille minimale requise.

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 (à l'exception de la clé de tri) à l'aide de la fonction ANALYZE COMPRESSION ou de la fonction Automatic Table Optimization d'Amazon Redshift. Amazon Redshift garantit l'encodage des colonnes. Il est recommandé d'utiliser cette fonctionnalité, même si elle augmente les performances de lecture et réduit la consommation globale de stockage.

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. Identifiez toutes les requêtes exécutées sur des tables pour lesquelles des statistiques sont manquantes. Le fait d'empêcher l'exécution de requêtes sur des tables contenant des statistiques manquantes empêche Amazon Redshift d'analyser des lignes de table inutiles. Cela permet également d'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;

En outre, utilisez la commande ANALYZE pour afficher et analyser les statistiques des tables.

Pour plus d'informations sur les opérations de maintenance, consultez l'utilitaire de schéma Amazon Redshift Analyze & Vacuum.

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 (Disque saturé), vérifiez la table STL_DISK_FULL_DIAG. Vérifiez l'ID de la requête à l'origine de l'erreur et les blocs temporaires qui ont été créés :

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. Notez quelles requêtes sont en cours d'exécution au moment d'un débordement de disque :

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;

Affichez la valeur de colonne blocks_to_disk pour identifier le débordement de disque. Arrêtez les requêtes qui débordent trop, si nécessaire. Ensuite, allouez de la mémoire supplémentaire aux requêtes avant de les exécuter de nouveau. Pour plus de détails, consultez STL_QUERY_METRICS.

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 commande identifie également les requêtes qui débordent sur le disque.

---

Informations connexes

Performances

Présentation du système Amazon Redshift