Déboguer les hotspots de votre base de données

Cette page explique comment détecter et déboguer les points chauds dans votre base de données. Vous pouvez accéder aux statistiques sur les points chauds dans les divisions avec GoogleSQL et PostgreSQL.

Spanner stocke vos données sous la forme d'un espace de clés contigu, ordonné par les clés primaires de vos tables et index. Une division est une plage de lignes d'un ensemble de tables ou d'un index. Le début de la division est appelé début de la division. La limite de fractionnement définit la fin du fractionnement. La division inclut le début de la division, mais pas la limite de division.

Dans Spanner, les hotspots sont des situations où un trop grand nombre de requêtes envoyées au même serveur, ce qui sature les ressources du serveur et peut entraîner des latences élevées. Les fractionnements affectés par les hotspots sont connus sous forme de divisions hot ou warm.

La statistique de point d'accès d'une division (identifiée dans le système sous le nom CPU_USAGE_SCORE) est une mesure de la charge sur une division limitée par les ressources disponibles sur le serveur. Cette mesure est fournie sous forme de pourcentage. Si plus de 50 % de la charge d'une division est limitée par les ressources disponibles, la division est considérée comme chaude. Si 100% de la charge lorsqu'une division est soumise à une contrainte, elle est considérée comme chaude.

Spanner utilise la répartition basée sur la charge pour répartir uniformément la charge de données sur les serveurs de l'instance. Les répartitions tiède et à chaud peuvent être déplacées entre les serveurs pour l’équilibrage de charge ou peuvent être divisées en divisions plus petites. Toutefois, Spanner peut ne pas être en mesure d'équilibrer la charge, même après plusieurs tentatives de fractionnement, en raison d'anti-modèles dans l'application. Par conséquent, les hotspots persistants qui durent au moins 10 minutes peuvent nécessiter davantage le dépannage et les modifications potentielles de l'application.

Les statistiques sur les divisions à chaud de Spanner vous aident à identifier les divisions où les hotspots se produisent. Vous pouvez ensuite modifier votre application ou votre schéma si nécessaire. Vous pouvez récupérer ces statistiques Tables système SPANNER_SYS.SPLIT_STATS_TOP_MINUTE à l'aide d'instructions SQL

Disponibilité des statistiques de fractionnement en temps réel

Spanner fournit les statistiques de division chaude dans le schéma SPANNER_SYS. Les données SPANNER_SYS ne sont disponibles que via les interfaces Google SQL et PostgreSQL. Toi peuvent utiliser les méthodes suivantes pour accéder à ces données:

• Page Spanner Studio d'une base de données dans la console Google Cloud
• La commande gcloud spanner databases execute-sql
• L'API executeQuery

Les API de lecture unique Spanner ne sont pas compatibles avec SPANNER_SYS.

Statistiques de répartition à chaud

Le tableau suivant vous permet de suivre les fractionnements à chaud:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE: affiche les fractionnements actifs à des intervalles d'une minute.

Ces tables ont les propriétés suivantes :

• Chaque table contient des données pour des intervalles de temps sans chevauchement de la durée spécifié par le nom de la table.

• Les intervalles sont basés sur l'heure:

  • Les intervalles d'une minute se terminent chaque minute.

• Après chaque intervalle, Spanner collecte les données de tous les serveurs, puis les met à disposition dans les tables SPANNER_SYS peu de temps après.

  Par exemple, à 11:59:30, les intervalles les plus récents disponibles pour les requêtes SQL sont les suivants :

  • 1 minute : 11:58:00-11:58:59

• Spanner regroupe les statistiques par division.

• Chaque ligne contient un pourcentage qui indique l'état chaud ou tiède d'une division, pour chaque division pour laquelle Spanner enregistre des statistiques pendant l'intervalle spécifié.

• Si moins de 50% de la charge sur un fractionnement est limitée par la ressources, Spanner ne capture pas la statistique. Si Spanner ne peut pas stocker toutes les divisions à chaud pendant le le système donne la priorité aux fractionnements ayant Pourcentage de CPU_USAGE_SCORE pendant l'intervalle spécifié. Si aucune division n'est renvoyée, cela signifie qu'il n'y a pas de points chauds.

Schéma de la table

Le tableau suivant présente le schéma de la table pour les statistiques suivantes :

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE

Nom de la colonne	Type	Description
INTERVAL_END	TIMESTAMP	Fin de l'intervalle de temps pendant lequel le fractionnement était à chaud
SPLIT_START	STRING	Clé de début de la plage de lignes dans la division. Le début du fractionnement peut également être <begin>, indiquant le début de l'espace clé.
SPLIT_LIMIT	STRING	Clé de limite pour la plage de lignes dans la division. La limite: clé peut également être <end>, indiquant la fin de l'espace clé|
CPU_USAGE_SCORE	INT64	Pourcentage de divisions : CPU_USAGE_SCORE. A Un pourcentage de CPU_USAGE_SCORE de 50% indique la présence de | chauds ou chauds. fractionnements |
AFFECTED_TABLES	STRING ARRAY	Tables dont les lignes peuvent être dans la division

Remarque : Les répartitions avec des pourcentages CPU_USAGE_SCORE inférieurs à 100 % peuvent être utilisées pour suivre les tendances au fil du temps. Spanner utilise la répartition basée sur la charge pour équilibrer la charge entre les serveurs. Vous pouvez donc constater que les divisions changent ou diminuent au fil du temps. Toutefois, Spanner peut ne pas être en mesure d'équilibrer la charge en raison de modèles problématiques dans l'application, et des divisions chaudes peuvent persister après plusieurs itérations de la division basée sur la charge de Spanner. Par conséquent, la présence de divisions à chaud pendant plus de 10 minutes est une indique que vous devrez peut-être approfondir votre enquête.

Que sont les clés de début et de limite de fractionnement ?

Une division est une plage de lignes contiguës d'une base de données. Elle est définie par son début et les clés de limite. Une division peut être une seule ligne, une plage de lignes étroite ou une plage de lignes large, et peut inclure plusieurs tables ou index.

Les colonnes SPLIT_START et SPLIT_LIMIT identifient les clés primaires d'une clé ou la répartition à chaud.

Exemple de schéma

Le schéma suivant est un exemple de table pour les sujets de cette page.

GoogleSQL

CREATE TABLE Users (
  UserId INT64 NOT NULL,
  FirstName STRING(MAX),
  LastName STRING(MAX),
) PRIMARY KEY(UserId);

CREATE INDEX UsersByFirstName ON Users(FirstName DESC);

CREATE TABLE Threads (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  Starred BOOL,
) PRIMARY KEY(UserId, ThreadId),
  INTERLEAVE IN PARENT Users ON DELETE CASCADE;

CREATE TABLE Messages (
  UserId INT64 NOT NULL,
  ThreadId INT64 NOT NULL,
  MessageId INT64 NOT NULL,
  Subject STRING(MAX),
  Body STRING(MAX),
) PRIMARY KEY(UserId, ThreadId, MessageId),
  INTERLEAVE IN PARENT Threads ON DELETE CASCADE;

CREATE INDEX MessagesIdx ON Messages(UserId, ThreadId, Subject),
INTERLEAVE IN Threads;

PostgreSQL

CREATE TABLE users
(
   userid    BIGINT NOT NULL PRIMARY KEY,-- INT64 to BIGINT
   firstname VARCHAR(max),-- STRING(MAX) to VARCHAR(MAX)
   lastname  VARCHAR(max)
);

CREATE INDEX usersbyfirstname
  ON users(firstname DESC);

CREATE TABLE threads
  (
    userid   BIGINT NOT NULL,
    threadid BIGINT NOT NULL,
    starred  BOOLEAN, -- BOOL to BOOLEAN
    PRIMARY KEY (userid, threadid),
    CONSTRAINT fk_threads_user FOREIGN KEY (userid) REFERENCES users(userid) ON
    DELETE CASCADE -- Interleave to Foreign Key constraint
  );

CREATE TABLE messages
  (
    userid    BIGINT NOT NULL,
    threadid  BIGINT NOT NULL,
    messageid BIGINT NOT NULL PRIMARY KEY,
    subject   VARCHAR(max),
    body      VARCHAR(max),
    CONSTRAINT fk_messages_thread FOREIGN KEY (userid, threadid) REFERENCES
    threads(userid, threadid) ON DELETE CASCADE
  -- Interleave to Foreign Key constraint
  );

CREATE INDEX messagesidx ON messages(userid, threadid, subject), REFERENCES
threads(userid, threadid);

Imaginez que votre espace clé ressemble à ceci:

PRIMARY KEY
<begin>
Users()
Threads()
Users(2)
Users(3)
Threads(3)
Threads(3,"a")
Messages(3,"a",1)
Messages(3,"a",2)
Threads(3, "aa")
Users(9)
Users(10)
Threads(10)
UsersByFirstName("abc")
UsersByFirstName("abcd")
<end>

Exemple de fractionnement

Vous trouverez ci-dessous quelques exemples de fractionnements pour vous aider à comprendre à quoi ressemblent les fractionnements. que vous aimez.

SPLIT_START et SPLIT_LIMIT peuvent indiquer la ligne d'une table ou d'un indice, ou <begin> et <end>, qui représentent les limites de l'espace de clés de la base de données. SPLIT_START et SPLIT_LIMIT peuvent également contenir les clés tronquées, qui sont des clés précédant toute clé complète dans la table. Par exemple : Threads(10) est un préfixe pour toute ligne Threads entrelacée dans Users(10).

SPLIT_START	SPLIT_LIMIT	AFFECTED_TABLES	EXPLICATION
Users(3)	Users(10)	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à la ligne avec UserId=3 et se termine à la ligne précédant celle avec UserId = 10. La division contient les lignes de la table Users et toutes les lignes de la table entrelacée de UserId=3 à 10.
Messages(3,"a",1)	Threads(3,"aa")	Threads, Messages, MessagesIdx	La division commence à la ligne avec UserId=3, ThreadId="a" et MessageId=1, et se termine à la ligne précédant celle avec la clé UserId=3 et ThreadsId = "aa". La division contient toutes les tables comprises entre Messages(3,"a",1) et Threads(3,"aa"). Comme split_start et split_limit sont entrelacés dans la même ligne de table de niveau supérieur, la division contient les lignes de table entrelacées entre le début et la limite. Consultez schemas-overview pour comprendre comment les tables entrelacées sont colocalisées.
Messages(3,"a",1)	<end>	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence dans la table des messages au niveau de la ligne avec les clés UserId=3, ThreadId="a" et MessageId=1. La division héberge toutes les lignes de split_start à <end>, c'est-à-dire la fin de l'espace clé de la base de données. Toutes les lignes des tables suivant la split_start, comme Users(4), sont incluses dans la division.
<begin>	Users(9)	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à <begin>, au début de l'espace de clés de la base de données, et se termine à la ligne précédant la ligne Users avec UserId=9. La division comporte donc toutes les lignes de la table précédant Users, ainsi que toutes les lignes de la table Users précédant UserId=9, ainsi que les lignes de ses tables entrelacées.
Messages(3,"a",1)	Threads(10)	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à Messages(3,"a", 1) entrelacée dans Users(3) et se termine à la ligne précédant Threads(10). Threads(10) est une clé de fractionnement tronquée qui est un préfixe de n'importe quelle clé du tableau "Threads" entrelacée dans Users(10).
Users()	<end>	UsersByFirstName, Users, Threads, Messages et MessagesIdx	Le fractionnement commence au niveau de la clé de division tronquée de Users() qui précède toute clé complète de la table Users. La division s'étend jusqu'à la fin de l'espace clé possible dans la base de données. Les tables affected_tables couvrent donc la table Users, ses tables et index entrelacés, ainsi que toutes les tables susceptibles d'apparaître après les utilisateurs.
Threads(10)	UsersByFirstName("abc")	UsersByFirstName, Users, Threads, Messages et MessagesIdx	La division commence à la ligne Threads avec UserId = 10 et se termine à l'index, UsersByFirstName à la clé précédant "abc".

Remarque : SPLIT_LIMIT est supérieur à SPLIT_START. Toutefois, les comparaisons lexicographiques du début et de la limite de fractionnement peuvent ne pas fonctionner entre les fractionnements.

Exemples de requêtes permettant de trouver des divisions à chaud

L'exemple suivant montre une instruction SQL que vous pouvez utiliser pour récupérer les statistiques de fractionnement chaud. Vous pouvez exécuter ces instructions SQL les bibliothèques clientes, gcloud ou la console Google Cloud.

GoogleSQL

SELECT t.split_start,
       t.split_limit,
       t.cpu_usage_score,
       t.affected_tables,
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end =
  (SELECT MAX(interval_end)
  FROM    SPANNER_SYS.SPLIT_STATS_TOP_MINUTE)
ORDER BY  t.cpu_usage_score DESC;

PostgreSQL

SELECT t.split_start,
       t.split_limit,
       t.cpu_usage_score,
       t.affected_tables
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end = (
  SELECT MAX(interval_end)
  FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE
)
ORDER BY t.cpu_usage_score DESC;

La sortie de la requête se présente comme suit :

SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE	AFFECTED_TABLES
Users(13)	Users(76)	82	Messages,Users,Threads
Users(101)	Users(102)	90	Messages,Users,Threads
Threads(10, "a")	Threads(10, "aa")	100	Messages,Threads
Messages(631, "abc", 1)	Messages(631, "abc", 3)	100	Messages
Threads(12, "zebra")	Users(14)	76	Messages,Users,Threads
Users(620)	<end>	100	Messages,Users,Threads

Conservation des données pour les statistiques de répartition active

Spanner conserve au minimum les données de chaque table pour les éléments suivants : période:

• SPANNER_SYS.SPLIT_STATS_TOP_MINUTE : intervalles couvrant les six heures précédentes

Remarque :Vous ne pouvez pas empêcher Spanner de collecter les statistiques de répartition à chaud. Pour supprimer les données de ces tables, vous devez supprimer la base de données associée aux tables ou attendre Spanner supprime les données automatiquement. La durée de conservation de ces tables est fixe. Si vous souhaitez conserver les statistiques sur de plus longues durées, nous vous recommandons de copier régulièrement les données de ces tables.

Résoudre les problèmes liés aux points d'accès à l'aide des statistiques de fractionnement à chaud

Cette section explique comment détecter et résoudre les problèmes liés aux points chauds.

Sélectionner la période à examiner

Vérifiez les métriques de latence de votre Base de données Spanner pour trouver la période pendant laquelle votre application une latence élevée et une utilisation élevée du processeur. Par exemple, il peut vous indiquer qu'un problème a commencé vers 22h50 le 18 mai 2024.

Identifier le hotspotting persistant

Étant donné que Spanner équilibre la charge avec la répartition basée sur la charge, nous vous recommandons de déterminer si le hotspotting s'est produit pendant plus de 10 minutes. Pour ce faire, interrogez la table SPANNER_SYS.SPLIT_STATS_TOP_MINUTE, comme illustré dans l'exemple suivant :

GoogleSQL

SELECT Count(DISTINCT t.interval_end)
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.utilization >= 50
  AND  t.interval_end >= "interval_end_date_time"
  AND  t.interval_end <= "interval_end_date_time";

Remplacez interval_end_date_time par la date et l'heure du intervalle, au format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT COUNT(DISTINCT t.interval_end)
FROM   SPLIT_STATS_TOP_MINUTE t
WHERE  t.utilization >= 50
  AND  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

Si le résultat de la requête précédente est égal à 10, cela signifie que votre base de données présente un point chaud qui peut nécessiter un débogage supplémentaire.

Trouver les écrans fractionnés ayant le niveau CPU_USAGE_SCORE le plus élevé

Pour cet exemple, nous exécutons la requête SQL suivante pour trouver les plages de lignes avec le niveau CPU_USAGE_SCORE le plus élevé :

GoogleSQL

SELECT t.split_start,
       t.split_limit,
       t.affected_tables,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score >= 50
  AND  t.interval_end = "interval_end_date_time";

Remplacez interval_end_date_time par la date et l'heure du intervalle, au format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.split_start,
       t.split_limit,
       t.affected_tables,
       t.cpu_usage_score
FROM   SPLIT_STATS_TOP_MINUTE t
WHERE  t.cpu_usage_score = 100
  AND  t.interval_end = 'interval_end_date_time'::timestamptz;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

L'instruction SQL précédente génère les résultats suivants :

SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE	AFFECTED_TABLES
Users(180)	<end>	85	Messages,Users,Threads
Users(24)	Users(76)	76	Messages,Users,Threads

Ce tableau de résultats montre que des hotspots sont apparus sur deux écrans fractionnés. La répartition basée sur la charge dans Spanner peut tenter de résoudre les hotspots. sur ces écrans fractionnés. Toutefois, il se peut qu'il ne puisse pas le faire s'il existe des schémas problématiques dans le schéma ou la charge de travail. Pour détecter les divisions nécessitant une intervention, nous vous recommandons de suivre les temps de passage minutes. Par exemple, la requête SQL suivante suit la première division au cours des dix dernières minutes.

GoogleSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.split_start = "users(180)"
  AND  t.split_limit = "<end>"
  AND  t.interval_end >= "interval_end_date_time"
  AND  t.interval_end <= "interval_end_date_time";

Remplacez interval_end_date_time par la date et l'heure du intervalle, au format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t.cpu_usage_score
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.split_start = 'users(180)'
  AND  t.split_limit = ''
  AND  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

Le code SQL précédent génère le résultat suivant:

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-18T17:46:00Z	Users(180)	<end>	85
2024-05-18T17:47:00Z	Users(180)	<end>	85
2024-05-18T17:48:00Z	Users(180)	<end>	85
2024-05-18T17:49:00Z	Users(180)	<end>	85
2024-05-18T17:50:00Z	Users(180)	<end>	85

La scission semble avoir été chaude ces dernières minutes. Vous pourriez observer pour déterminer si la clé de service Spanner la division limite le hotspotting. Il peut y avoir des cas où Spanner ne peut plus équilibrer la charge.

Par exemple, interrogez SPANNER_SYS.SPLIT_STATS_TOP_MINUTE. tableau. Consultez les exemples de scénarios suivants.

GoogleSQL

SELECT t.interval_end,
      t.split_start,
      t.split_limit,
      t.cpu_usage_score
FROM  SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE t.interval_end >= "interval_end_date_time"
      AND t.interval_end <= "interval_end_date_time";

Remplacez interval_end_date_time par la date et l'heure du intervalle, au format 2024-05-18T17:40:00Z.

PostgreSQL

SELECT t.interval_end,
       t.split_start,
       t.split_limit,
       t._cpu_usage
FROM   SPANNER_SYS.SPLIT_STATS_TOP_MINUTE t
WHERE  t.interval_end >= 'interval_end_date_time'::timestamptz
  AND  t.interval_end <= 'interval_end_date_time'::timestamptz;

Remplacez interval_end_date_time par la date et l'heure de l'intervalle, au format 2024-05-18T17:40:00Z.

Ligne active unique

Dans l'exemple suivant, il semble que Threads(10,"spanner") se trouve dans une seule division de ligne qui est restée active pendant plus de 10 minutes. Cela peut se produire lorsque il y a une charge persistante sur une ligne populaire.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:41:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:42:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:43:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:44:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:45:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	62
2024-05-16T20:46:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:47:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:48:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	80
2024-05-16T20:49:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	100
2024-05-16T20:50:00Z	Threads(10,"spanner")	Threads(10,"spanner1")	100

Spanner ne peut pas équilibrer la charge de cette clé unique, car elle ne peut pas sont divisés davantage.

Point d'accès mobile

Dans l'exemple suivant, la charge passe par des divisions contiguës au fil du temps, passer à une nouvelle répartition sur des intervalles de temps.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(1,"a")	Threads(1,"aa")	100
2024-05-16T20:41:00Z	Threads(1,"aa")	Threads(1,"ab")	100
2024-05-16T20:42:00Z	Threads(1,"ab")	Threads(1,"c")	100
2024-05-16T20:43:00Z	Threads(1,"c")	Threads(1,"ca")	100

Cela peut se produire, par exemple, en raison d'une charge de travail qui lit ou écrit des clés dans un ordre monotone croissant. Spanner ne peut pas équilibrer la charge pour atténuer les effets de ce comportement de l'application.

Équilibrage de charge normal

Spanner tente d'équilibrer la charge en ajoutant des divisions déplacer les écrans. L'exemple suivant montre à quoi cela pourrait ressembler.

INTERVAL_END	SPLIT_START	SPLIT_LIMIT	CPU_USAGE_SCORE
2024-05-16T20:40:00Z	Threads(1000,"zebra")	<end>	82
2024-05-16T20:41:00Z	Threads(1000,"zebra")	<end>	90
2024-05-16T20:42:00Z	Threads(1000,"zebra")	<end>	100
2024-05-16T20:43:00Z	Threads(1000,"zebra")	Threads(2000,"spanner")	100
2024-05-16T20:44:00Z	Threads(1200,"c")	Threads(2000)	92
2024-05-16T20:45:00Z	Threads(1500,"c")	Threads(1700,"zach")	76
2024-05-16T20:46:00Z	Threads(1700)	Threads(1700,"c")	76
2024-05-16T20:47:00Z	Threads(1700)	Threads(1700,"c")	50
2024-05-16T20:48:00Z	Threads(1700)	Threads(1700,"c")	39

Ici, la division la plus importante du 16/05/2024 17:40:00Z a été divisée en une division plus petite. Par conséquent, la statistique CPU_USAGE_SCORE a diminué. Spanner ne peut pas créer de divisions en lignes individuelles. Les écrans fractionnés mettez en miroir la charge de travail à l'origine de la statistique CPU_USAGE_SCORE élevée.

Si vous avez observé un fractionnement à chaud persistant pendant plus de 10 minutes, reportez-vous à la section Meilleure pour limiter les hotspots.

Bonnes pratiques pour limiter la création de hotspots

Remarque : Si votre charge a augmenté et que vous avez récemment mis à l'échelle votre instance, Spanner peut mettre quelques minutes à effectuer ses opérations d'équilibrage de charge avant que votre latence ne diminue.

Si l'équilibrage de charge ne réduit pas la latence, l'étape suivante consiste à identifier la cause des hotspots. Ensuite, vous pouvez réduire la charge de travail de point chaud ou optimiser le schéma et la logique de l'application pour éviter les points chauds.

Identifier la cause

• Utilisez les insights sur les verrouillages et les transactions pour rechercher les transactions dont le temps d'attente de verrouillage est élevé, où la clé de début de la plage de lignes se trouve dans la division active.

• Utilisez Query Insights pour rechercher les requêtes qui lisent des données depuis la table qui contient la division à chaud, et ont récemment augmenté la latence ou un ratio plus élevé de latence au processeur.

• Utilisez Requêtes actives les plus anciennes pour rechercher les requêtes qui lisent à partir du tableau contenant la division chaude et qui ont une latence supérieure à celle attendue.

Voici quelques cas particuliers à prendre en compte :

• Vérifiez si la valeur TTL (Time To Live) a été activée récemment. S'il y a de nombreuses divisions à partir d'anciennes données, la valeur TTL peut augmenter CPU_USAGE_SCORE lors des suppressions en masse. Dans ce cas, le problème devrait se résoudre automatiquement une fois les suppressions initiales terminées.

Optimiser la charge de travail

• Suivez les bonnes pratiques SQL. Envisagez des lectures obsolètes, des écritures qui n'effectuent pas de lectures en premier ou l'ajout d'index.
• Suivez les bonnes pratiques concernant les schémas. Assurez-vous que votre schéma est conçu pour gérer et d'éviter les hotspots.

Étape suivante

• Découvrez les bonnes pratiques concernant la conception de schémas.
• Découvrez Key Visualizer.
• Consultez des exemples de conception de schémas.
• Découvrez comment utiliser le tableau de bord "Insights sur les points d'accès partagés".