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

Cette page présente les erreurs de dépassement du délai Spanner : ce qu'elles sont, 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épassement du délai peut se produire pour de nombreuses raisons, par exemple en cas de surcharge des instances Spanner, de schémas non optimisés ou de requêtes non optimisées. Cette page décrit les scénarios courants dans lesquels une erreur de dépassement du délai se produit. Elle fournit également un guide sur la façon d'examiner et de résoudre ces problèmes.

Philosophie 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 d'expiration comme durée maximale pendant laquelle une réponse est utile. Il n'est pas recommandé de définir un délai artificiellement court juste pour réessayer immédiatement la même opération, car cela entraînera des situations où les opérations ne se termineront 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 réessai 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 la latence de queue et ne peut pas se terminer avant d'expirer. Définissez plutôt un délai 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 ne soit dépassé. Cela entraîne des nouvelles tentatives et du travail inutile à chaque essai. Globalement, cela peut créer une charge supplémentaire importante sur votre instance.

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

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

Le guide de configuration des délais d'attente montre comment spécifier des délais (ou des délais d'attente) 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 les délais.

Examiner et résoudre les erreurs courantes de dépassement 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 liés à l'API d'accès aux données. Les sections suivantes décrivent comment examiner et résoudre différents problèmes liés à l'API d'accès aux données.

Vérifier la charge CPU de l'instance Spanner

La latence des requêtes peut augmenter considérablement lorsque l'utilisation du processeur dépasse le seuil 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 transite du client vers les serveurs Spanner et inversement, plusieurs sauts réseau 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 à la base de données Spanner. Si des problèmes de réseau surviennent à l'une de ces étapes, 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 dans une requête Spanner. Pour identifier où la latence se produit dans Spanner, consultez 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 schémas 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 vérifier ces schémas 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épassement du délai peut s'afficher. Voici quelques exemples de requêtes coûteuses (liste non exhaustive) : analyses complètes 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 "Statistiques de requête" et de la table "Statistiques de transaction". Ces tableaux affichent des informations sur les requêtes et les transactions lentes, comme le nombre moyen de lignes lues, le nombre moyen d'octets lus, le nombre moyen de lignes analysées, etc. Vous pouvez également 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 à partir des tables de statistiques mentionnées précédemment et des 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 vous aider à réduire le temps d'exécution des instructions, ce qui peut vous aider à éviter les erreurs de dépassement du délai.

Vérifier les conflits de verrouillage

Les transactions Spanner doivent acquérir des verrous pour être validées. Les applications s'exécutant à un débit élevé peuvent entraîner la concurrence des transactions pour les mêmes ressources, ce qui augmente le temps d'attente pour obtenir les verrous et a un impact sur les performances globales. Cela peut entraîner le dépassement des délais pour toute demande de lecture ou d'écriture.

Pour identifier la cause première des transactions de lecture/écriture à latence élevée, consultez le tableau des statistiques de verrouillage et lisez cet article de blog. Dans le tableau des statistiques de verrouillage, vous trouverez les clés de ligne avec les temps d'attente de verrouillage les plus élevés.

Ce guide de dépannage des conflits de verrouillage explique comment identifier les transactions qui accèdent aux colonnes impliquées dans le conflit de verrouillage. Vous pouvez également identifier les transactions 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 mixtes en lecture/écriture. En suivant ces étapes, vous devriez améliorer la latence globale du temps d'exécution de vos transactions et réduire les erreurs de dépassement du 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 sous-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 configuré.

Solution

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

Vérifier les zones cliquables

Spanner étant une base de données distribuée, la conception du schéma doit tenir compte de la prévention des points chauds. Par exemple, la création de colonnes à valeurs croissantes de manière monotone limitera 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 d'attente. Vous pouvez également utiliser Key Visualizer pour résoudre les problèmes de performances causés par les points chauds.

Solution

Pour résoudre ce problème, commencez par consulter les solutions identifiées dans la section précédente Vérifier les 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 provoquer des hotspots. Si ces étapes ne permettent pas d'atténuer le problème, consultez le guide sur le choix d'une clé primaire pour éviter les points d'accès. Enfin, évitez les schémas de trafic sous-optimaux tels que les lectures de grandes plages, qui peuvent empêcher la répartition basée sur la charge.

Vérifier si les délais d'attente sont mal configurés

Les bibliothèques clientes fournissent des délais d'attente par défaut raisonnables pour toutes les requêtes dans Spanner. Toutefois, ces configurations par défaut peuvent nécessiter des ajustements pour votre charge de travail spécifique. Il est important d'observer le coût de vos requêtes et d'ajuster les délais pour qu'ils soient adaptés à votre cas d'utilisation spécifique.

Solution

Les paramètres de délai avant expiration par défaut conviennent à la plupart des cas d'utilisation. Les utilisateurs peuvent remplacer ces configurations (consultez le guide personnalisé sur les délais d'attente et les nouvelles tentatives), mais il n'est pas recommandé d'utiliser des délais d'attente 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 requêtes d'administrateur 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 d'administrateur d'instance et de base de données. Cela permet au serveur de traiter la requête avant que le client ne réessaie ou n'échoue.

Solution

Si vous utilisez la bibliothèque cliente Spanner de Google pour accéder à l'API Administrator, assurez-vous que la bibliothèque cliente est à jour et qu'elle utilise la dernière version. Si vous accédez à l'API Spanner directement via une bibliothèque cliente que vous avez créée, assurez-vous de ne pas avoir défini de paramètres de délai plus agressifs que les paramètres par défaut (60 minutes) pour les demandes d'administrateur d'instance et de base de données.

Google Cloud  Problèmes liés à la console

Les requêtes émises depuis la page Spanner Studio de la console Google Cloud ne peuvent 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 de la console Google Cloud dépassé"

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 les 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 de 15 secondes pour les opérations de commit. Ces configurations permettent des opérations plus longues par rapport aux délais avant expiration des bibliothèques clientes autonomes. Toutefois, il est toujours possible de recevoir une erreur de délai avant expiration et de délai dépassé lorsque les éléments de travail sont trop volumineux. Si nécessaire, vous pouvez personnaliser la configuration du délai avant expiration des commits Apache Beam.

Solution

Si une erreur de dépassement du délai se produit à l'étape ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions, consultez le tableau des statistiques sur les 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 présenté 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û à la taille trop importante des éléments de travail. Dans l'exemple précédent, les deux recommandations suivantes peuvent être utiles. Tout d'abord, vous pouvez essayer d'activer le service de lecture aléatoire s'il ne l'est pas encore. Deuxièmement, vous pouvez essayer de modifier les configurations de 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 obtenir un exemple, consultez ce modèle Dataflow.

Ressources supplémentaires pour résoudre les problèmes de dépassement de délai

Si l'erreur DEADLINE_EXCEEDED s'affiche toujours après avoir suivi les étapes de dépannage, créez une demande d'assistance si vous rencontrez les problèmes suivants :

  • Latence Google Front End élevée, mais latence de requête 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 :