Pourquoi est-ce que j'observe une utilisation élevée du processeur sur mon nœud principal Amazon Redshift ?

Brève description

Le nœud principal de votre cluster Amazon Redshift analyse et développe des plans d'exécution pour effectuer des opérations de base de données. Le nœud principal effectue également le traitement final des requêtes et la fusion ou le tri des données avant de renvoyer ces données au client. Selon la complexité ou l'utilisation intensive des opérations de base de données, l'utilisation du processeur peut augmenter pour le nœud principal de votre cluster.

En particulier, l'utilisation du processeur de votre nœud principal peut s’accroître pour les raisons suivantes :

• Augmentation des connexions aux bases de données
• Compilation et recompilation des requêtes
• Nombre élevé de connexions simultanées
• Nombre élevé de requêtes simultanées exécutées dans WLM
• Fonctions de nœuds principaux uniquement et requêtes de catalogue

Remarque : vous ne pouvez pas vérifier les processus spécifiques qui occupent votre nœud principal. Utilisez la table STV_RECENTS pour vérifier quelles requêtes s'exécutent à un moment donné.

Solution

Augmentation des connexions aux bases de données

Le serveur client communique avec le cluster Amazon Redshift via le nœud principal. S'il y a un nombre croissant de connexions de base de données, l'utilisation du processeur augmente afin de traiter ces connexions. Vérifiez les métriques Amazon CloudWatch pour vous assurer que la limite DatabaseConnections n'a pas été dépassée.

Compilation et recompilation des requêtes

Amazon Redshift génère et compile du code pour chaque plan d'exécution de requête. La compilation et la recompilation de requêtes sont des opérations gourmandes en ressources, ce qui peut entraîner une utilisation élevée du processeur du nœud principal. Cependant, les performances du processeur doivent revenir à la normale lorsque les opérations de compilation ou de recompilation de requêtes sont terminées.

En outre, Amazon Redshift met en cache le code compilé. Lorsqu'une requête est soumise, Amazon Redshift réutilise tous les segments disponibles pendant que les segments restants sont recompilés. Par conséquent, ce processus peut contribuer à accroître l’utilisation du processeur du nœud principal.

Remarque : après le redémarrage d'un cluster Amazon Redshift, le segment compilé persiste, même si le cache des résultats est vidé. Amazon Redshift n'exécutera pas la requête si celle-ci a été précédemment mise en cache. Tous les caches sont supprimés lorsqu'un correctif est appliqué.

Pour vérifier la durée de compilation (en seconde) et l'emplacement d'exécution du segment pour chaque segment de requête, utilisez la vue système SVL_COMPILE :

select userid,xid,pid,query,segment,locus,starttime, endtime,
datediff(second,starttime,endtime) as TimetoCompile,compile from svl_compile;

Nombre élevé de connexions simultanées

Un plus grand nombre de connexions peut entraîner une simultanéité plus élevée et une augmentation du nombre de transactions de votre cluster Amazon Redshift. L'augmentation du nombre de transactions peut entraîner une utilisation élevée du processeur du nœud principal.

Pour vérifier la présence de connexions simultanées, exécutez la requête suivante :

select s.process as process_id,
c.remotehost || ':' || c.remoteport as remote_address,
s.user_name as username,
s.starttime as session_start_time,
s.db_name,
i.starttime as current_query_time,
i.text as query 
from stv_sessions s
left join pg_user u on u.usename = s.user_name
left join stl_connection_log c
on c.pid = s.process
and c.event = 'authenticated'
left join stv_inflight i 
          on u.usesysid = i.userid
          and s.process = i.pid
where username <> 'rdsdb'
order by session_start_time desc;

Ensuite, utilisez PG_TERMINATE_BACKEND pour fermer les sessions actives.

Nombre élevé de requêtes simultanées exécutées dans WLM

Toutes les connexions client sont traitées via le nœud principal. Avant de renvoyer les données au serveur client, le nœud principal Amazon Redshift analyse, optimise et compile les requêtes. Le nœud principal distribue également les tâches aux nœuds de calcul, effectuant le tri ou l'agrégation finaux. Avec une simultanéité élevée des requêtes, l'utilisation du processeur peut augmenter au niveau du nœud principal. En outre, certaines opérations de base de données ne peuvent être appliquées qu'au niveau du nœud principal. Par exemple, une requête avec une clause LIMIT peut avoir une consommation élevée du processeur, car la limite est appliquée au nœud principal avant que les données ne soient redistribuées.

Pour connaître s'il existe une corrélation entre le nombre de requêtes simultanées et l'utilisation du processeur, vérifiez d’abord les métriquesWLMRunningQueries et CPUutilization dans Amazon CloudWatch.

Ensuite, vérifiez pour voir quelles requêtes ont une consommation élevée du processeur :

SELECT userid, query, xid, aborted,
ROUND(query_cpu_time::decimal,3),
query_execution_time,
segment_execution_time,
substring(querytxt,1,250)
FROM stl_query
JOIN
(SELECT query,
query_cpu_time,
query_execution_time,
segment_execution_time
FROM svl_query_metrics_summary
ORDER BY 2 DESC) a USING (query)
WHERE userid>1
AND starttime BETWEEN '2019-12-02 22:00:00' and '2019-12-05 23:59:59'
ORDER BY 5 DESC;

Vérifiez la sortie pour connaître quelles requêtes sont traitées par le nœud principal et toutes les autres requêtes aberrantes qui augmentent l'utilisation du processeur.

Remarque : il est recommandé de régler les performances des requêtes pour vos requêtes. Envisagez d'augmenter la capacité de votre nœud principal et de choisir des types de nœuds volumineux (plutôt que d'ajouter plus de nœuds de calcul).

Fonctions de nœuds principaux uniquement et requêtes de catalogue

Amazon Redshift implémente certaines fonctions SQL prises en charge par le nœud principal. S'il existe des requêtes complexes avec des fonctions de nœud principal ainsi que des requêtes de catalogue surchargées, l'utilisation du processeur peut augmenter sur un nœud principal. Pour plus d'informations, voir Fonctions SQL prises en charge par le nœud principal.

Pour identifier les étapes référençant les tables de catalogue (qui ne sont exécutées que sur un nœud principal), vérifiez le plan EXPLAIN :

explain select * from pg_class;
                           QUERY PLAN                          
----------------------------------------------------------------
 LD Seq Scan on pg_class  (cost=0.00..24.57 rows=557 width=243)

Vérifiez le préfixe LD dans votre sortie. Dans cet exemple, le préfixe LD est affiché dans « LD Seq Scan on pg_class (coût=0.00..24.57 lignes=557 largeur=243) ». Le préfixe LD indique qu'une requête s'exécute exclusivement sur un nœud principal, ce qui peut provoquer une augmentation de l'utilisation du processeur.

---