Résoudre les erreurs de dépassement de délai Spanner

Cette page présente les erreurs de dépassement du délai Spanner : en quoi elles consistent, pourquoi elles se produisent, et comment les résoudre.

Lorsque vous accédez aux API Spanner, les requêtes peuvent échouer en raison d'erreurs DEADLINE_EXCEEDED. Cette erreur indique qu'aucune réponse n'a été reçue dans le délai d'inactivité configuré.

Une erreur de délai dépassé peut se produire pour de nombreuses raisons, telles que des instances Spanner surchargées, des schémas non optimisés ou des requêtes non optimisées. Cette page décrit les scénarios courants dans lesquels une erreur de délai dépassé se produit et fournit un guide pour examiner et résoudre ces problèmes.

Politique de Spanner concernant les délais et les nouvelles tentatives

La philosophie de Spanner concernant les délais et les nouvelles tentatives diffère de celle de nombreux autres systèmes. Dans Spanner, vous devez spécifier un délai avant expiration comme durée maximale pendant laquelle une réponse est utile. Configurer une règle artificielle un court délai pour relancer immédiatement la même opération n'est pas car cela peut donner lieu à des situations où les opérations ne se terminent jamais. Dans ce contexte, les stratégies et opérations suivantes ne sont pas recommandées. Elles sont contre-productives et annulent le comportement de nouvelle tentative interne de Spanner :

  • Définir un délai trop court. Cela signifie que l'opération n'est pas résiliente aux augmentations occasionnelles de latence de la queue et qu'elle ne peut pas se terminer avant l'expiration du délai. Définissez plutôt une échéance correspondant à la durée maximale pendant laquelle une réponse est utile.

  • Définir un délai trop long et annuler l'opération avant que le le délai imparti. Cela entraîne des nouvelles tentatives et un travail inutile à chaque tentative. Dans l'ensemble, cela peut créer une charge supplémentaire importante sur votre instance.

Qu'est-ce qu'une erreur de dépassement de délai ?

Lorsque vous utilisez l'une des bibliothèques clientes Spanner, la couche gRPC sous-jacente gère la communication, le marshaling, le désérialisation et l'application des délais. Les délais permettent à votre candidature de préciser combien de temps qu'il est disposé à attendre qu'une requête se termine avant qu'elle ne soit interrompue. indiquant l'erreur "Délai dépassé".

Le guide de configuration du délai avant expiration montre comment spécifier des délais (ou des délais avant expiration) dans chacune des clés Spanner compatibles bibliothèques clientes. Les bibliothèques clientes Spanner utilisent les paramètres de délai d'expiration et de stratégie de nouvelle tentative définis par défaut dans les fichiers de configuration suivants :

Pour en savoir plus sur les délais gRPC, consultez la page gRPC et délais.

Examiner et résoudre les erreurs courantes liées à l'expiration du délai

Vous pouvez rencontrer des erreurs DEADLINE_EXCEEDED pour les types de problèmes suivants :

Problèmes liés à l'API d'accès aux données

Une instance Spanner doit être correctement configurée pour votre des charges de travail spécifiques pour éviter les problèmes d'API d'accès aux données. Les sections suivantes expliquent comment examiner et résoudre différents problèmes liés aux API d'accès aux données.

Vérifier la charge du processeur de l'instance Spanner

La latence des requêtes peut augmenter considérablement lorsque l'utilisation du processeur seuil opérationnel recommandé. Vous pouvez vérifier l'utilisation du processeur Spanner dans la console de surveillance fournie dans la console Google Cloud. Vous pouvez également créer des alertes en fonction de l'utilisation du processeur de l'instance.

Solution

Pour connaître les étapes permettant de réduire l'utilisation du processeur de l'instance, consultez la section Réduire l'utilisation du processeur.

Vérifier la répartition de la latence de bout en bout de la requête

Lorsqu'une requête est acheminée du client vers les serveurs Spanner et inversement, il y a plusieurs sauts de réseau qui doivent être effectués: de la bibliothèque cliente Google Front End (GFE); du GFE à l'interface de l'API Spanner. et enfin de l'interface de l'API Spanner Spanner. En cas de problèmes de réseau au niveau de l'un de ces des erreurs de dépassement du délai peuvent s'afficher.

Il est possible de capturer la latence à chaque étape. Pour en savoir plus, consultez Points de latence d'une requête Spanner Pour savoir où la latence se produit dans Spanner, consultez la section Identifier où la latence se produit dans Spanner.

Solution

Après avoir obtenu la répartition de la latence, vous pouvez analyser la latence à l'aide des métriques, comprendre pourquoi elle se produit et trouver des solutions.

Problèmes liés à l'API Data

Certains modèles d'utilisation non optimaux de l'API Data de Spanner peuvent entraîner des erreurs de dépassement du délai. Cette section explique comment pour détecter ces schémas d'utilisation non optimaux.

Rechercher les requêtes coûteuses

Essayer d'exécuter des requêtes coûteuses qui ne s'exécutent pas dans le délai avant expiration configuré dans les bibliothèques clientes peut entraîner une erreur de délai dépassé. Un peu Les requêtes coûteuses incluent, sans s'y limiter, les analyses complètes d'une table volumineuse, des jointures croisées sur plusieurs tables volumineuses ou une exécution de requête avec sur une colonne non-clé (également une analyse complète de la table).

Vous pouvez inspecter les requêtes coûteuses à l'aide du tableau des statistiques sur les requêtes. et le tableau des statistiques sur les transactions. Ces tableaux fournissent des informations sur les requêtes et les transactions lentes, telles que le nombre moyen de lignes lues, les octets lus en moyenne, le nombre moyen de lignes analysées, etc. Vous pouvez également générer des plans d'exécution de requêtes. pour inspecter plus en détail l'exécution de vos requêtes.

Solution

Pour optimiser vos requêtes, consultez le guide des bonnes pratiques pour les requêtes SQL. Vous pouvez également utiliser les données obtenues via les tableaux de statistiques mentionnés les plans précédents et d'exécution afin d'optimiser vos requêtes et d'apporter des modifications au schéma à vos bases de données. Ces bonnes pratiques peuvent vous aider à réduire le temps d'exécution les instructions, ce qui peut potentiellement aider à corriger les erreurs de dépassement de délai.

Rechercher des conflits de verrouillage

Les transactions Spanner doivent acquérir des verrous. à valider. Les applications fonctionnant à un débit élevé peuvent entraîner une concurrence entre les transactions pour les mêmes ressources, ce qui augmente le temps d'attente pour obtenir les verrous et affecte les performances globales. Cela peut entraîner le dépassement des délais de lecture ou d'écriture.

Pour identifier l'origine des transactions en lecture-écriture à latence élevée, consultez le tableau des statistiques de verrouillage et l'article de blog suivant. Dans le tableau des statistiques de verrouillage, vous trouverez les clés de ligne ayant temps d'attente pour le verrouillage.

Ce guide de dépannage des conflits de verrouillage explique comment trouver les transactions qui accèdent aux colonnes impliquées dans le conflit de verrouillage. Vous pouvez également identifier les transactions concernées par un conflit de verrouillage à l'aide du guide de dépannage avec les tags de transaction.

Solution

Appliquer ces bonnes pratiques pour réduire les conflits de verrouillage. De plus, utilisez des transactions en lecture seule pour les cas d'utilisation de lecture simple afin d'éviter les conflits de verrouillage avec les écritures. En utilisant Les transactions en lecture-écriture doivent être réservées aux écritures ou aux workflows mixtes de lecture/écriture. Suivez ces étapes pour améliorer la latence globale de votre transaction la durée d'exécution et réduire les erreurs de dépassement de délai.

Rechercher les schémas non optimisés

Avant de concevoir un schéma de base de données optimal pour votre base de données Spanner, vous devez tenir compte des types de requêtes qui seront exécutées dans votre base de données. Les schémas non optimaux peuvent entraîner des problèmes de performances lors de l'exécution de certaines requêtes. Ces problèmes de performances peuvent empêcher les requêtes de se terminer dans le délai défini.

Solution

La conception de schéma la plus optimale dépend des lectures et des écritures effectuées dans votre base de données. Les guides Bonnes pratiques de conception de schémas et Bonnes pratiques SQL doivent être suivis, quelles que soient les spécificités du schéma. En suivant ces guides, vous évitez le schéma le plus courant les problèmes de conception. D'autres causes des mauvaises performances sont attribuées à votre choix de clés primaires, à la mise en page des tables (voir Utiliser des tables entrelacées pour un accès plus rapide), à la conception du schéma (voir Optimiser le schéma pour améliorer les performances) et aux performances du nœud configuré dans votre instance Spanner (voir Présentation des performances de Spanner).

Rechercher des zones à fort trafic

Spanner étant une base de données distribuée, la conception du schéma doit tenir compte de la prévention des points d'accès. Par exemple, la création de colonnes à augmentation monotone limite le nombre de fractionnements avec lesquels Spanner peut travailler pour répartir la charge de travail de manière uniforme. Ces goulots d'étranglement peuvent entraîner dans les délais avant expiration. Vous pouvez également utiliser Key Visualizer pour résoudre les problèmes de performances causés par les hotspots.

Solution

Pour résoudre ce problème, consultez les solutions identifiées dans la section précédente Rechercher des schémas non optimisés. Repensez votre schéma de base de données et utilisez des index entrelacés pour éviter les index susceptibles de créer des hotspots. Si cette procédure ne permet pas pour atténuer le problème, consultez le guide Choisir une clé primaire pour éviter la création de hotspots. Enfin, évitez les modèles de trafic non optimaux, tels que les lectures de plage étendue, qui peuvent empêcher la répartition basée sur la charge.

Rechercher les délais avant expiration mal configurés

Les bibliothèques clientes fournissent des valeurs par défaut de délai d'expiration raisonnables pour toutes les requêtes dans Spanner. Cependant, ces configurations par défaut peuvent avoir besoin d'être pour une charge de travail spécifique. Il est utile d'évaluer le coût et ajuster les délais pour les adapter à votre cas d'utilisation spécifique.

Solution

Les paramètres par défaut des délais avant expiration conviennent à la plupart des cas d'utilisation. Les utilisateurs peuvent remplacez ces configurations (voir le guide concernant le délai d'expiration personnalisé et les nouvelles tentatives). mais il n'est pas recommandé d'utiliser des délais avant expiration plus agressifs que ceux par défaut. Si vous décidez de modifier le délai d'expiration, définissez-le sur la durée réelle pendant laquelle l'application est prête à attendre le résultat. Vous pouvez tester des délais d'expiration plus longs, mais ne définissez jamais un délai d'expiration plus court que le délai attendu par l'application, car cela entraînerait une nouvelle tentative de l'opération plus souvent.

Problèmes liés à l'API Admin

Les requêtes de l'API Admin sont des opérations coûteuses par rapport aux requêtes de l'API Data. Les demandes d'administration comme CreateInstance, CreateDatabase ou CreateBackups peuvent met plusieurs secondes avant de renvoyer une réponse. Client Spanner Les bibliothèques définissent des délais de 60 minutes pour les deux instances. et base de données les demandes de l'administrateur. Cela permet de s'assurer que le serveur a la possibilité de terminer la requête avant que le client ne réessaie ou ne rencontre un échec.

Solution

Si vous utilisez la bibliothèque cliente Spanner Google Spanner pour accéder à l'API Admin, vérifiez que la bibliothèque cliente est à jour et utilise la dernière version version. Si vous accédez à l'API Spanner directement via un bibliothèque cliente que vous avez créée, vérifiez que vous n'avez pas de délais plus ambitieux que les paramètres par défaut (60 minutes) de votre instance et base de données les demandes de l'administrateur.

Problèmes liés à Google Cloud Console

Les requêtes émises à partir de la page Spanner Studio de la console Google Cloud ne doivent pas dépasser cinq minutes. Si vous créez une requête coûteuse nécessitant plus de minutes, le message d'erreur suivant s'affiche:

Capture d'écran du message d'erreur "Délai dépassé" dans la console Google Cloud

Le backend annulera la requête ayant échoué, et la transaction pourra être annulée. si nécessaire.

Solution

Vous pouvez réécrire la requête en suivant le guide des bonnes pratiques pour les requêtes SQL.

Problèmes liés à Dataflow

Dans Apache Beam, la configuration du délai avant expiration par défaut est de deux heures. pour les opérations de lecture et 15 secondes pour les opérations de commit. Ces configurations permettent des opérations plus longues lorsque par rapport aux délais avant expiration de la bibliothèque cliente autonome. Toutefois, il est toujours possible de recevoir un message d'erreur de délai avant expiration et de dépassement de l'échéance lorsque les éléments de travail sont trop volumineux. Si nécessaire, vous pouvez personnaliser la configuration du délai avant expiration de la validation Apache Beam.

Solution

Si une erreur de délai dépassé se produit dans les étapes ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, consultez le tableau des statistiques des requêtes pour identifier la requête qui a analysé un grand nombre de lignes. Modifiez ensuite ces requêtes pour essayer de réduire le temps d'exécution.

Un autre exemple d'erreur de dépassement du délai Dataflow est affiché dans le message d'exception suivant :

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

Ce délai avant expiration s'est produit, car les éléments de travail sont trop volumineux. Dans l'exemple précédent, les deux recommandations suivantes peuvent vous aider. Tout d'abord, vous pouvez essayer d'activer le service de lecture aléatoire s'il n'est pas encore activé. Deuxièmement, vous pouvez essayer d'ajuster les configurations de la lecture de votre base de données, telles que maxPartitions et partitionSizeBytes. Pour en savoir plus, consultez PartitionOptions pour essayer de réduire la taille de l'élément de travail. Pour savoir comment procéder, consultez ce modèle Dataflow.

L'échéance supplémentaire a dépassé les ressources de dépannage

Si une erreur DEADLINE_EXCEEDED s'affiche toujours après avoir terminé la procédure de dépannage, ouvrez une demande d'assistance si vous êtes confronté aux scénarios suivants:

  • Une latence Google Front End élevée, mais une faible latence des requêtes API Spanner
  • Latence élevée des requêtes API Spanner, mais faible latence des requêtes

Vous pouvez également consulter les ressources de dépannage suivantes :