Résoudre les problèmes de latence
Comme tout système de base de données, Bigtable peut rencontrer des problèmes de latence. Ce document aborde les causes courantes des problèmes de latence dans Bigtable et explique comment les résoudre.
Diagnostiquez et résolvez les problèmes de latence Bigtable en suivant les étapes de dépannage décrites dans les sections suivantes :
Comprendre les causes de la latence élevée
Les facteurs suivants contribuent aux problèmes de latence dans Bigtable :
- Latence du serveur. La mesure de la latence du serveur commence lorsque Bigtable reçoit la requête et se termine lorsque Bigtable envoie le dernier octet de données au client. Pour les requêtes portant sur de grands volumes de données, la capacité du client à consommer la réponse peut avoir une incidence sur la latence du serveur.
- Les latences des opérations mesurent la durée totale de bout en bout d'une opération Bigtable, y compris toutes les nouvelles tentatives. Cette métrique suit l'aller-retour d'une opération depuis le client vers Bigtable, puis retourne au client. La latence de votre application, la connexion réseau, la latence de la bibliothèque cliente Bigtable et les latences du serveur ont toutes une incidence sur la latence des opérations.
- Les charges de travail et les modèles de requêtes peuvent augmenter la latence non seulement en raison d'un problème d'infrastructure, mais aussi en raison d'une modification du modèle de travail demandé par l'application. Par exemple, une requête d'analyse générée de manière dynamique qui analysait auparavant une centaine de lignes en analyse désormais un million en raison d'une importation de données récente ou d'une modification de la logique de l'application. Bien que le système puisse fonctionner efficacement, l'augmentation significative de la quantité de travail pour une seule opération entraîne un temps d'exécution plus long, que Bigtable perçoit comme une latence plus élevée.
Avant de commencer
Pour résoudre les problèmes de latence élevée, procédez comme suit :
- Activez les métriques côté client pour votre bibliothèque cliente afin d'optimiser vos performances et de résoudre les problèmes.
- Pour minimiser la latence du réseau, vérifiez que votre application réside dans la même zone que votre cluster Bigtable. Cela réduit la distance réseau entre votre application et votre cluster, ce qui améliore les temps de réponse des requêtes.
- Rassemblez les informations suivantes sur votre environnement Bigtable :
- Rassemblez les informations suivantes sur votre environnement côté client :
- Rassemblez les informations suivantes sur le problème :
Résoudre les problèmes de latence
Si vous rencontrez des problèmes de latence dans Bigtable, suivez ces étapes pour les résoudre :
- Vérifier la latence du serveur : utilisez la page "Monitoring" de la consoleGoogle Cloud pour afficher la latence du serveur. Pour en savoir plus, consultez Surveiller avec Cloud Monitoring. Vérifiez la latence de votre instance. Si l'instance contient plusieurs clusters, segmentez la métrique par cluster. Si vous constatez une augmentation de la latence dans les graphiques de latence de lecture ou d'écriture, ou dans les métriques côté client, suivez les étapes de dépannage de la latence du serveur dans la section Résoudre les problèmes de latence du serveur de ce document.
- Vérifier la latence du client : après avoir activé les métriques côté client, recherchez
bigtable.googleapis.com/client
dans l'explorateur de métriques Cloud Monitoring. Consultez les métriques côté client disponibles. Si vous constatez une latence accrue dans les métriques côté client, mais pas sur le serveur, examinez votre application et votre connexion réseau. Pour en savoir plus, consultez la section Résoudre les problèmes de latence du client de ce document.
Le schéma suivant illustre le processus de dépannage en cas d'augmentation de la latence dans Bigtable :
Résoudre les problèmes de latence du client
Pour résoudre les problèmes de latence côté client, procédez comme suit.
Avant de commencer
Avant de commencer à résoudre les problèmes de latence côté client, effectuez les tâches suivantes :
- Activez les métriques côté client dans Bigtable.
- Activez l'amorçage de canal si vous utilisez un client Java version 2.17.1 ou antérieure. L'actualisation des chaînes est activée par défaut à partir de la version 2.18.0.
- Itérez pour déterminer la taille optimale du pool de connexions pour votre charge de travail. Un nombre de canaux insuffisant ou excessif peut entraîner une latence élevée des tentatives.
Vérifier les latences de blocage des applications
Vérifiez la métrique Application Blocking Latencies
dans la console Google Cloud , puis effectuez l'une des actions suivantes :
- Si les latences bloquant les applications sont élevées et correspondent à l'augmentation de la latence signalée, concentrez-vous sur la résolution des problèmes côté client.
- Si les latences de blocage des applications sont élevées et que le client est hébergé sur une infrastructureGoogle Cloud , telle que GKE ou Compute Engine, escaladez le problème à l'équipe d'assistance Google Cloud appropriée.
- Si les latences de blocage des applications sont faibles et que la latence de diffusion Bigtable l'est également, le goulot d'étranglement de la latence se situe probablement dans un composant intermédiaire du chemin réseau ou du trafic, tel que le réseau ou le frontend Google. Envisagez de contacter l'équipe réseau Google Cloudpour obtenir une capture complète des paquets et identifier le goulot d'étranglement de la latence.
Résoudre les problèmes de latence élevée des opérations
- Si
connectivity_error_count
est élevé, l'application a du mal à atteindre le frontend Google. Définissez des délais d'attente RPC plus courts afin que la requête puisse être relancée sur différents canaux.- Si le délai avant expiration du RPC est trop faible, cela peut également entraîner des latences d'opération élevées. Déterminez le délai avant expiration RPC P99 typique lors des opérations normales. Définir une valeur de délai avant expiration RPC plus proche de ce benchmark permet d'optimiser les performances.
- Si
retry_count
est élevé, vérifiez le tag d'étatattempt_latencies
. Si les tentatives échouent avec des erreursDEADLINE_EXCEEDED
, cela signifie que le délai de la requête est trop court par rapport à la durée moyenne deattempt_latencies
.
Traiter les requêtes mises en file d'attente sur le thread gRPC
Si aucune métrique ne dépasse la norme, les requêtes peuvent être mises en file d'attente sur le thread gRPC. Cela peut être dû aux raisons suivantes :
- La taille du pool de canaux est trop petite et les requêtes sont mises en file d'attente dans les canaux gRPC. Pour en savoir plus, consultez Requêtes mises en mémoire tampon.
- L'utilisation du processeur de la VM cliente est élevée. Une utilisation élevée du processeur entraîne également la mise en file d'attente des requêtes dans le client.
Résoudre les problèmes de latence du serveur
Suivez ces étapes pour résoudre les problèmes de latence côté serveur.
Déterminer si le cluster est surchargé
- Vérifiez si les graphiques
Read requests
etWrite requests
indiquent des changements dans les RPS. - Vérifiez si le nombre de nœuds a changé dans le graphique
Node count
. - Vérifiez si la bande passante a augmenté dans les graphiques
Read throughput
etWrite throughput
. Pour en savoir plus, consultez Analyser les performances. - Pour identifier la façon dont le processeur est utilisé par profil d'application, méthode et tableau afin de résoudre les problèmes de performances, consultez l'article de blog Où votre cluster Cloud Bigtable utilise-t-il son processeur ?.
- Augmentez le nombre de nœuds dans le cluster concerné. Pour en savoir plus, consultez Ajouter ou supprimer des nœuds manuellement et Autoscaling. Vérifiez que l'utilisation moyenne du processeur reste inférieure au seuil recommandé.
Rechercher les points d'accès
Un tablet suractif utilise un pourcentage disproportionné du processeur d'un nœud par rapport aux autres tablets associés à ce nœud. Ce déséquilibre peut être dû à un volume élevé et inattendu de requêtes envoyées à une plage de lignes ou à des défauts dans la conception du schéma. Ce déséquilibrage dans l'utilisation du nœud peut entraîner une latence plus élevée et augmenter les délais de réplication, ce que l'on appelle des points chauds.
- Observez les points chauds dans le graphique
CPU utilization (hottest node) high granularity
. - Pour identifier les tablets suractifs, utilisez hot tablets ou l'outil Key Visualizer.
- Contrairement à la surutilisation du processeur au niveau du cluster, que vous pouvez souvent atténuer en ajoutant des nœuds (scaling horizontal), les points d'accès peuvent nécessiter d'autres techniques d'atténuation. Ces techniques incluent la modification de la façon dont vous construisez les clés de ligne ou le schéma. Pour en savoir plus, consultez l'article de blog Éliminer les points chauds dans Cloud Bigtable.
Résoudre les problèmes de latence avec un faible RPS
Bigtable fonctionne mieux avec les tables volumineuses auxquelles vous accédez fréquemment. Si vous envoyez des requêtes après une période d'inactivité, vous constaterez peut-être une latence élevée pendant que Bigtable rétablit les connexions.
- Si les graphiques
Read requests
etWrite requests
affichent un faible RPS, attendez-vous à des temps de réponse plus lents. - Pour atténuer les problèmes de démarrage à froid, suivez les bonnes pratiques décrites dans Démarrages à froid et faible nombre de requêtes par seconde.
Évaluer l'efficacité des requêtes
Évaluez l'efficacité des requêtes à l'aide des statistiques sur les requêtes. Les statistiques sur les requêtes indiquent le ratio entre les lignes vues et les lignes renvoyées, ainsi qu'entre les cellules vues et les cellules renvoyées, ce qui indique l'efficacité des requêtes. Améliorez l'efficacité des requêtes en réexaminant les modèles de requêtes ou la conception du schéma. Pour en savoir plus, consultez Obtenir des statistiques sur les requêtes.
Vérifier les modifications de configuration ou de profil d'application
Si le nombre de nœuds et le débit restent inchangés, mais que l'utilisation moyenne du processeur augmente, cela peut être dû à des modifications des stratégies de réplication ou de récupération de mémoire. Pour en savoir plus, consultez Réplication et performances. Rétablit les modifications de configuration apportées à la réplication ou à la récupération de mémoire.
Transmettre à l'assistance Bigtable
Si les étapes précédentes ne permettent pas de résoudre le problème, contactez l'assistance Bigtable.
Étapes suivantes
- En savoir plus sur les performances de Bigtable
- Consultez Métriques Bigtable.
- Explorez les métriques disponibles dans Key Visualizer.