Résoudre les erreurs de délai dépassé 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.

Philosophie de Spanner concernant l'échéance 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. Il est déconseillé de définir un délai artificiellement court juste pour réessayer immédiatement la même opération, car cela peut entraîner des situations où les opérations ne sont jamais terminées. 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 qu'il n'expire. 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élai dépassé ?

Lorsque vous utilisez l'une des bibliothèques clientes Spanner, la couche gRPC sous-jacente gère la communication, le marshaling, le désmarshaling et l'application des délais. Les délais permettent à votre application de spécifier la durée pendant laquelle elle est prête à attendre la fin d'une requête avant qu'elle ne soit arrêtée avec l'erreur "Délai dépassé".

Le guide de configuration des délais explique comment spécifier des échéances (ou délais) dans chacune des bibliothèques clientes Spanner compatibles. 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 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 vos charges de travail spécifiques afin d'é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 de manière significative lorsque l'utilisation du processeur dépasse le seuil sain 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 savoir comment réduire l'utilisation du processeur de l'instance, consultez 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 passe du client aux serveurs Spanner et inversement, plusieurs sauts réseau doivent être effectués: de la bibliothèque cliente au Google Front End (GFE), du GFE à l'interface de l'API Spanner, et enfin de l'interface de l'API Spanner à la base de données Spanner. En cas de problème réseau à l'une de ces étapes, des erreurs de délai dépassé peuvent s'afficher.

Il est possible de capturer la latence à chaque étape. Pour en savoir plus, consultez la section Points de latence dans 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

Une fois que vous avez obtenu la répartition de la latence, vous pouvez utiliser des métriques pour diagnostiquer la latence, 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 fournit des instructions sur la façon de rechercher ces modèles d'utilisation non optimaux.

Rechercher les requêtes coûteuses

Si vous essayez 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, une erreur de délai dépassé peut s'afficher. Voici quelques exemples de requêtes coûteuses, mais la liste n'est pas exhaustive : analyse complète d'une grande table, jointures croisées sur plusieurs grandes tables ou exécution d'une requête avec un prédicat sur une colonne non clé (également une analyse complète de la table).

Vous pouvez inspecter les requêtes coûteuses à l'aide de la table des statistiques de requête et de la table des statistiques de transaction. 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. De plus, vous pouvez générer des plans d'exécution de requêtes pour examiner plus en détail la façon dont vos requêtes sont exécutées.

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 tables de statistiques mentionnées précédemment et les plans d'exécution pour optimiser vos requêtes et apporter des modifications de schéma à vos bases de données. Ces bonnes pratiques peuvent contribuer à réduire le temps d'exécution des instructions, ce qui peut aider à éliminer les erreurs de délai dépassé.

Vérifier les conflits de verrouillage

Les transactions Spanner doivent acquérir des verrous pour être validées. 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 pour toutes les requêtes 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 pouvez trouver les clés de ligne présentant les temps d'attente de verrouillage les plus élevés.

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 découvrir quelles transactions sont impliquées dans un conflit de verrouillage à l'aide du guide de dépannage avec les tags de transaction.

Solution

Appliquez 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. L'utilisation de transactions en lecture-écriture doit être réservée aux écritures ou aux workflows en lecture-écriture mixtes. En suivant ces étapes, vous devriez améliorer la latence globale du temps d'exécution de votre transaction et réduire les erreurs d'expiration dépassée.

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 d'être traitées dans le délai configuré.

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 les problèmes de conception de schéma les plus courants. 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 sensibles

Comme Spanner est une base de données distribuée, la conception de schéma doit tenir compte de la prévention des points chauds. 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 des délais avant expiration. Vous pouvez également utiliser Key Visualizer pour résoudre les problèmes de performances causés par des points chauds.

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 le problème persiste, consultez le guide Choisir une clé primaire pour éviter de créer des hotspots. Enfin, évitez les modèles de trafic non optimaux, tels que les lectures de plages étendues, 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 avant expiration raisonnables pour toutes les requêtes dans Spanner. Toutefois, vous devrez peut-être ajuster ces configurations par défaut en fonction de votre charge de travail spécifique. Il est utile d'observer le coût de vos requêtes et d'ajuster les délais en fonction de 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 remplacer ces configurations (voir le guide sur le délai avant expiration et la nouvelle tentative personnalisés), mais il est déconseillé d'utiliser des délais avant expiration plus agressifs que les valeurs 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 requêtes d'administration telles que CreateInstance, CreateDatabase ou CreateBackups peuvent prendre plusieurs secondes avant de renvoyer une réponse. Les bibliothèques clientes Spanner définissent des délais de 60 minutes pour les requêtes des administrateurs d'instance et de base de données. 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 de Google pour accéder à l'API administrateur, assurez-vous qu'elle est à jour et qu'elle utilise la dernière version. Si vous accédez directement à l'API Spanner via une bibliothèque cliente que vous avez créée, assurez-vous que les paramètres de délai ne sont pas plus agressifs que les paramètres par défaut (60 minutes) pour les requêtes de l'instance et de l'administrateur de base de données.

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 qui prend plus de cinq minutes à s'exécuter, 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 par défaut du délai avant expiration est de deux heures pour les opérations de lecture et de 15 secondes pour les opérations de validation. Ces configurations permettent des opérations plus longues 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 est dû au fait que 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 suivi les étapes de dépannage, ouvrez une demande d'assistance si les scénarios suivants se produisent:

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

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