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 présente 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 d'une 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é d'utilisation de la réponse au niveau du client peut affecter la latence du serveur.
- Les latences d'opération mesurent la durée totale de bout en bout d'une opération Bigtable, y compris toutes les nouvelles tentatives. Cette métrique mesure 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 modèles de charge de travail et de requête peuvent augmenter la latence non seulement en raison d'un problème d'infrastructure, mais également en raison d'un changement 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 se trouve 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 résoudre le problème :
- Vérifiez la latence du serveur : utilisez la page "Surveillance" 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 observez 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/clientdans l'explorateur de métriques Cloud Monitoring. Examinez les métriques côté client disponibles. Si vous constatez une augmentation de la latence 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 d'une latence accrue dans Bigtable :
Résoudre les problèmes de latence du client
Suivez ces étapes pour résoudre les problèmes de latence côté client.
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 canaux est activée par défaut à partir de la version 2.18.0.
- Effectuez des itérations pour déterminer la taille optimale du pool de connexions pour votre charge de travail. Un nombre insuffisant ou excessif de canaux peut entraîner des latences de tentative élevées.
Vérifier les latences de blocage des applications
Vérifiez la métrique Application Blocking Latencies dans la console Google Cloud et effectuez l'une des actions suivantes :
- Si les latences de blocage de l'application 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 de l'application sont élevées et que le client est hébergé sur l'infrastructureGoogle Cloud , telle que GKE ou Compute Engine, faites remonter le problème à l'équipe d'assistance Google Cloud appropriée.
- Si les latences de blocage de l'application sont faibles et que la latence de diffusion de Bigtable est également faible, le goulot d'étranglement de la latence se situe probablement dans un composant intermédiaire du réseau ou du chemin de trafic, tel que le réseau ou l'interface Google. Envisagez de faire remonter le problème à l'équipe réseau Google Cloudpour qu'elle vous aide à effectuer une capture complète des paquets afin d'identifier le goulot d'étranglement de la latence.
Résoudre les problèmes de latence élevée des opérations
- Si
connectivity_error_countest élevé, l'application a du mal à atteindre l'interface Google. Définissez des délais avant expiration 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 standard lors d'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_countest élevé, vérifiez le tag d'étatattempt_latencies. Si les tentatives échouent avec des erreursDEADLINE_EXCEEDED, le délai avant expiration de la requête est trop court par rapport à la moyenne deattempt_latencies.
Requêtes d'adresse mises en file d'attente sur le thread gRPC
Si aucune des métriques 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 les graphiques
Read requestsetWrite requestspour voir si le nombre de RPS a changé. - Vérifiez si le nombre de nœuds a changé dans le graphique
Node count. - Vérifiez les graphiques
Read throughputetWrite throughputpour détecter les augmentations de bande passante. Pour en savoir plus, consultez la page Analyser les performances. - Pour identifier comment le processeur est utilisé par profil d'application, méthode et table afin de résoudre les problèmes de performances, consultez l'article de blog Où votre cluster Cloud Bigtable dépense-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 hotspots
Un tablet suractif utilise un pourcentage disproportionné du processeur d'un nœud par rapport aux autres tablets associés à ce nœud. Cette utilisation déséquilibrée peut être due à un volume de requêtes élevé et imprévu sur 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 qu'on appelle des hotspots.
- Observez les hotspots dans le graphique
CPU utilization (hottest node) high granularity. - Pour identifier les tablets suractifs, utilisez les tablets suractifs 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 hotspots 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 la modification du schéma. Pour en savoir plus, consultez l'article de blog Éliminer les hotspots dans Cloud Bigtable.
Résoudre les problèmes de latence avec un faible nombre de RPS
Bigtable fonctionne mieux avec les tables volumineuses fréquemment consultées. 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 requestsetWrite requestsaffichent un faible nombre de RPS, attendez-vous à des temps de réponse plus lents. - Pour limiter 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 de la page Modèles d'accès et des statistiques de requête :
- Utilisez la page Modèles d'accès de la console Google Cloud pour surveiller la répartition des types de requêtes de lecture et d'écriture au fil du temps (par exemple, les lectures ponctuelles, les analyses courtes, les analyses inversées, les lectures éparses et les lectures groupées) et comparer les lignes analysées et les cellules vues aux lignes renvoyées et aux cellules envoyées pour vos tables et profils d'application. Pour en savoir plus, consultez Analyser les modèles d'accès.
- Utilisez les statistiques de requête pour inspecter le ratio de lignes vues par rapport aux lignes renvoyées et de cellules vues par rapport aux cellules renvoyées pour les requêtes de lecture individuelles. Améliorez l'efficacité des requêtes en revoyant les schémas de requête, les filtres ou la conception du schéma. Pour en savoir plus, consultez Obtenir des statistiques sur les requêtes.
Vérifier les modifications apportées à la configuration ou au 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. Annulez les modifications de configuration apportées à la réplication ou à la récupération de mémoire.
Faire remonter le problème à l'assistance Bigtable
Si les étapes précédentes ne permettent pas de résoudre le problème, escaladez-le à 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.