FAQ et dépannage des métriques de surveillance Hologres - Hologres

Cette rubrique répond aux questions fréquentes concernant les métriques de surveillance de Hologres, notamment l'utilisation élevée du processeur, la pression sur la mémoire, les requêtes lentes et les performances d'écriture.

Comment afficher et interrompre les connexions lorsque leur nombre est trop élevé ?

Les connexions incluent toutes les connexions SQL actives et inactives d'une instance, qu'elles proviennent de Java Database Connectivity (JDBC) ou de PSQL. Si vous rencontrez l'une des erreurs suivantes, cela signifie que l'instance a atteint sa limite de connexions :

FATAL: sorry, too many clients already connection limit exceeded for superusers
FATAL: remaining connection slots are reserved for non-replication superuser connections

Consultez les connexions actives via HoloWeb ou en exécutant une requête SQL. Pour plus de détails, reportez-vous à la section Gérer les connexions. Utilisez ensuite un compte superutilisateur pour interrompre les connexions inattendues ou inactives.

Que faire si la latence des requêtes est trop élevée ?

Commencez par identifier les instructions SQL lentes dans le journal des requêtes lentes. Pour en savoir plus, consultez la section Obtenir et analyser les journaux des requêtes lentes. Appliquez ensuite la solution adaptée à votre situation :

Faible nombre de requêtes par seconde (QPS) mais SQL complexe : optimisez les instructions SQL et définissez des index appropriés. Reportez-vous aux sections Optimiser les performances des requêtes sur les tables internes et Accélérer les requêtes MaxCompute.
QPS élevé : si le code SQL est déjà optimisé mais que vous avez besoin d'un QPS plus élevé et d'une latence réduite, augmentez la capacité de l'instance. Consultez la section Instances.

Opérations d'écriture impactant les performances des requêtes : effectuez les écritures pendant les heures creuses ou réduisez la simultanéité des écritures. Pour les tables externes MaxCompute, utilisez les paramètres suivants afin de limiter la simultanéité :

-- Limit MaxCompute execution concurrency. Default: 128. A lower value prevents one query from affecting others.
SET hg_experimental_foreign_table_executor_max_dop = 32;

-- Reduce the batch size for each read from a MaxCompute table. Default: 8192.
SET hg_experimental_query_batch_size = 1024;

-- Read ORC files directly.
SET hg_experimental_enable_access_odps_orc_via_holo = on;

-- Increase the split size for large MaxCompute tables to reduce the number of concurrent tasks. Default: 64 MB.
SET hg_experimental_foreign_table_split_size = 512MB;

Quelles sont les causes d'une utilisation élevée de la mémoire et comment y remédier ?

Hologres utilise un modèle de réservation de mémoire : même en l'absence de requêtes actives, les métadonnées, les index et les caches de données sont chargés en mémoire pour accélérer la récupération des informations. Une utilisation de la mémoire comprise entre 30 % et 40 % est normale lorsqu'aucune requête n'est en cours d'exécution.

Lorsque l'utilisation de la mémoire augmente progressivement pour atteindre 80 %, cela indique généralement l'une des deux situations suivantes :

Volume de données croissant : le nombre de tables et le volume total de données dépassent largement les ressources de calcul actuelles. L'utilisation de la mémoire évolue proportionnellement à la quantité de métadonnées et d'index.
Tables sur-indexées : les tables comportant de nombreuses colonnes, principalement de type TEXT, ainsi qu'un excès d'index bitmap ou de dictionnaire, consomment une quantité disproportionnée de mémoire.

Une utilisation soutenue de la mémoire proche de 80 % peut entraîner des problèmes de stabilité, tels que les erreurs SERVER_INTERNAL_ERROR, ERPC_ERROR_CONNECTION_CLOSED ou Total memory used by all existing queries exceeded memory limitation, ainsi qu'une dégradation des performances, comme une réduction du taux de succès du cache et une augmentation de la latence des requêtes.

Pour résoudre ce problème :

Supprimez les données inutilisées afin de libérer la mémoire occupée par les métadonnées.
Supprimez les index inutiles : si les index bitmap ou de dictionnaire ne sont pas utilisés par votre charge de travail, supprimez-les à l'aide de la commande ALTER TABLE. Analysez vos besoins métier avant de supprimer tout index.
Augmentez les ressources de calcul et de stockage :
- Scénarios généraux : 1 unité de calcul (CU), soit 1 vCPU + 4 Go de mémoire, prend en charge 50 à 100 Go de stockage de données.
- Service à faible latence : pour des performances optimales, les données fréquemment accédées doivent tenir dans le cache mémoire. Le cache occupe 30 % de la mémoire totale, donc une instance de 1 CU offre 1,3 Go pour le cache de données. Pour 100 Go de données fréquemment accédées, vous avez besoin d'au moins 320 Go de mémoire (soit 96 CU ou plus).

Pourquoi l'utilisation du processeur d'une instance Hologres atteint-elle 100 % avec une seule tâche ?

Hologres est conçu pour exploiter pleinement le calcul parallèle multicœur. Une seule requête peut porter l'utilisation du processeur à 100 %, ce qui signifie simplement que les ressources de calcul sont entièrement utilisées. Il s'agit d'un comportement attendu et non d'un problème. La situation devient problématique uniquement si cette utilisation élevée du processeur ralentit les requêtes ou les écritures. Consultez la section Que faire si l'utilisation du processeur reste à 100 % pendant une longue période ? pour diagnostiquer et résoudre ce type de situation.

Comment résoudre les lenteurs d'écriture ?

Si les commandes INSERT, INSERT ON CONFLICT ou UPDATE prennent trop de temps, la cause la plus probable est que le code SQL n'utilise pas de plan fixe (Fixed Plan). Le code SQL sans plan fixe est soumis à des verrous de table : en cas d'exécution simultanée, chaque instruction attend la libération du verrou, ce qui allonge considérablement la durée d'exécution. Dans la métrique de surveillance Real-time Write RPS, ces opérations apparaissent sous le type d'écriture insert.

Pour résoudre ce problème, réécrivez le code SQL afin d'utiliser un plan fixe. Le type d'écriture dans la métrique Real-time Write RPS passe alors à SDK et les performances s'améliorent. Pour plus de détails, consultez la section Accélérer l'exécution SQL avec des plans fixes.

Que faire si l'utilisation du processeur reste à 100 % pendant une longue période ?

Une utilisation élevée et soutenue du processeur — 100 % pendant 3 heures consécutives ou plus, ou supérieure à 90 % pendant 12 heures consécutives ou plus — indique que le processeur est devenu un goulot d'étranglement système. Effectuez les vérifications suivantes dans l'ordre.

Vérification 1 : Le QPS ou le RPS a-t-il augmenté de manière significative ?

Comparez les métriques QPS et RPS avant et après le pic d'utilisation du processeur. Si vous observez une tendance clairement ascendante :

Pour les pics liés aux requêtes SELECT : utilisez le journal des requêtes lentes pour identifier les requêtes de longue durée et optimisez-les.
Pour les pics liés aux opérations INSERT/UPDATE/DELETE : vérifiez si ces opérations contournent le plan fixe. Le code SQL sans plan fixe entraîne des verrous de table et des attentes de verrou lors de l'exécution simultanée.
```
-- Find INSERT/UPDATE/DELETE operations that did not use a Fixed Plan in the last 3 hours.
SELECT *
FROM hologres.hg_query_log
WHERE query_start >= now() - INTERVAL '3 h'
  AND command_tag IN ('INSERT', 'UPDATE', 'DELETE')
  AND 'HQE' = ANY(engine_type)
ORDER BY query_start DESC
LIMIT 500;
```
Le cas échéant, réécrivez ces instructions pour utiliser un plan fixe. Si tout le code SQL est déjà optimisé, augmentez la capacité de l'instance ou mettez en place une séparation lecture/écriture. Consultez les sections Mettre à niveau une instance ou Déployer des instances principale et secondaire pour la séparation lecture/écriture (stockage partagé).

Vérification 2 : Existe-t-il des requêtes de longue durée ?

Si le QPS et le RPS sont stables mais que l'utilisation du processeur augmente soudainement, examinez la métrique Running Query Duration. Les requêtes s'exécutant depuis plus de 30 minutes ou une heure consomment probablement le processeur en continu. Exécutez la requête suivante pour les identifier et les annuler :

-- Find long-running queries.
SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, pid::text
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY 1 DESC;

-- Cancel a query.
SELECT pg_cancel_backend(<pid>);

Vérification 3 : Certaines requêtes consomment-elles beaucoup de processeur ?

Utilisez le journal des requêtes lentes pour identifier les requêtes consommant le plus de processeur, de mémoire et d'E/S :

-- Find high-resource queries in the last 3 hours.
SELECT
  status                                    AS "Status",
  duration                                  AS "Duration (ms)",
  query_start                               AS "Start time",
  (read_bytes / 1048576)::text || ' MB'     AS "Read volume",
  (memory_bytes / 1048576)::text || ' MB'   AS "Memory",
  (shuffle_bytes / 1048576)::text || ' MB'  AS "Shuffle",
  (cpu_time_ms / 1000)::text || ' s'        AS "CPU time",
  physical_reads                            AS "Disk reads",
  query_id                                  AS "Query ID",
  query
FROM hologres.hg_query_log
WHERE query_start > current_timestamp - INTERVAL '3 h'
  AND command_tag IN ('SELECT', 'INSERT', 'UPDATE', 'DELETE')
  AND duration > 1000
ORDER BY duration DESC,
         read_bytes DESC,
         shuffle_bytes DESC,
         memory_bytes DESC,
         cpu_time_ms DESC,
         physical_reads DESC
LIMIT 500;

Optimisez les requêtes identifiées.

Vérification 4 : De nouvelles requêtes PQE apparaissent-elles ?

Vérifiez si de nouvelles requêtes PQE sont apparues au moment où l'utilisation du processeur a augmenté :

-- Find queries that used PQE in the last 3 hours.
SELECT *
FROM hologres.hg_query_log
WHERE query_start > current_timestamp - INTERVAL '3 h'
  AND 'PQE' = ANY(engine_type)
ORDER BY query_start DESC
LIMIT 500;

Si des requêtes PQE existent, optimisez les opérateurs SQL pour réduire ou éliminer l'utilisation de PQE. Consultez la section Optimiser les performances des requêtes.

Vérification 5 : Des index bitmap ou de dictionnaire ont-ils été récemment modifiés ?

La modification d'index bitmap ou de dictionnaire sur une table déclenche un processus asynchrone de compactage en arrière-plan qui consomme du processeur. L'utilisation du stockage augmente généralement dans un premier temps, puis diminue à mesure que le compactage se termine. Vérifiez les modifications d'index récentes :

-- Find index modification records in the last 3 hours.
SELECT *
FROM hologres.hg_query_log
WHERE query_start >= now() - INTERVAL '3 h'
  AND command_tag IN ('CALL')
ORDER BY query_start DESC
LIMIT 500;

Comment gérer les requêtes de longue durée ?

La métrique Running Query Duration affiche les requêtes dont la durée d'exécution dépasse le temps attendu, par exemple plus d'une heure. Consultez la page Active Query Tasks pour voir ce qui est actuellement en cours d'exécution. Pour plus de détails, reportez-vous à la section Gérer les requêtes.

Les requêtes de longue durée relèvent généralement de l'un des quatre scénarios suivants :

Opérations d'écriture continues : examinez la métrique Real-time Write RPS pour déterminer si des écritures massives en cours monopolisent les ressources.

Inactif dans une transaction : un client a ouvert une transaction et exécuté une opération DDL sans la valider. L'état de la requête apparaît comme idle in transaction dans pg_stat_activity. Pour les identifier :

-- Find long-running queries, including idle-in-transaction sessions.
SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, pid::text
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY 1 DESC;

Fermez la transaction côté client ou définissez un délai d'expiration pour les transactions inactives. Consultez la section Modifier le délai d'expiration des requêtes inactives. Pour annuler une requête bloquée :

SELECT pg_cancel_backend(<pid>);

Code SQL complexe utilisant PQE : exécutez EXPLAIN <sql> pour vérifier le plan d'exécution. Si la sortie contient External SQL (Postgres), la requête utilise PQE et peut s'exécuter lentement. Interrompez la requête, puis optimisez le code SQL pour réduire l'utilisation de PQE. Consultez la section Optimiser les performances des requêtes sur les tables internes.

Opérations DDL simultanées provoquant des conflits de verrouillage : les opérations DDL verrouillent les tables. Lorsque plusieurs instructions DDL s'exécutent simultanément, elles créent des conflits de verrouillage et de longues attentes. Vérifiez les opérations DDL en cours :

SELECT datname::text, usename, query, pid::text, state
FROM pg_stat_activity
WHERE state != 'idle';

Interrompez toute opération DDL bloquante pour libérer les verrous, puis exécutez les instructions DDL de manière séquentielle.

Comment dépanner les requêtes ayant échoué ?

La métrique Failed Queries indique le nombre de requêtes ayant échoué par seconde. N'utilisez pas uniquement le QPS pour estimer le nombre total d'échecs ; le total correspond à la surface sous la courbe (plage de temps x QPS). Utilisez le journal des requêtes lentes pour obtenir le compte exact et les motifs d'échec, puis résolvez les problèmes en fonction des erreurs spécifiques. Consultez la section Afficher et analyser les journaux des requêtes lentes.

Comment résoudre une charge processeur inégale entre les workers ?

Dans Hologres, les données sont partitionnées en shards. Un worker traite un ou plusieurs shards à la fois, et chaque shard ne peut être accessible que par un seul worker à la fois. Une charge inégale provient généralement de trois causes :

Déséquilibre des données : si un shard contient beaucoup plus de données que les autres, le worker qui lui est attribué supporte une charge disproportionnée. Vérifiez la présence d'un déséquilibre :

SELECT hg_shard_id, count(1) FROM <table_name> GROUP BY hg_shard_id;

-- Example output showing skew: shard 39 holds significantly more rows than others.
-- hg_shard_id | count
-- -------------+--------
--           53 |  29130
--           65 |  28628
--           66 |  26970
--           70 |  28767
--           77 |  28753
--           24 |  30310
--           15 |  29550
--           39 | 164983

Traitez les données déséquilibrées ou définissez une clé de distribution appropriée. Consultez la section Optimiser les performances des requêtes.

Le nombre de shards n'est pas un multiple du nombre de workers : lorsque le nombre de shards dans un groupe de tables n'est pas un multiple entier du nombre total de workers, certains workers reçoivent plus de shards que d'autres. Définissez un nombre de shards approprié en fonction des spécifications de l'instance. Consultez la section Gérer les groupes de tables et les nombres de shards. Cela affecte principalement les grandes instances (plus de 256 cœurs). Pour les instances plus petites, le nombre de shards par défaut est suffisant.

Redistribution inégale après le redémarrage d'un worker : lorsqu'un worker est arrêté en raison d'une erreur de mémoire insuffisante (OOM) ou pour d'autres raisons, le système migre rapidement les shards de ce worker vers d'autres workers afin de récupérer les requêtes sans délai. Lorsque le worker redémarre, le système lui réattribue certains shards. Si la charge de l'instance est faible, ce déséquilibre est sans conséquence. Si la charge est élevée, redémarrez l'instance pour redistribuer les shards de manière équitable.