Ce document explique comment interpréter les résultats de performances dans AlloyDB Omni sur une VM. Dans ce document, nous partons du principe que vous connaissez bien PostgreSQL.
Lorsque vous représentez graphiquement le débit dans le temps alors qu'une autre variable est modifiée, vous constatez généralement que le débit augmente jusqu'à atteindre un point d'épuisement des ressources.
La figure ci-après montre un graphique typique d'ajustement du débit. À mesure que le nombre de clients augmente, la charge de travail et le débit augmentent, jusqu'à ce que toutes les ressources soient épuisées.
Dans l'idéal, le débit devrait doubler lorsque la charge sur le système double. En pratique, il y aura un conflit de ressources qui entraînera une augmentation plus faible du débit. À un moment donné, l'épuisement ou le conflit de ressources entraîneront une stabilisation, voire une diminution du débit. Si vous optimisez le débit, il s'agit d'un point clé à identifier, car il permet d'orienter vos efforts vers l'endroit où vous devez ajuster le système d'application ou de base de données pour améliorer le débit.
Voici quelques raisons courantes pour lesquelles le débit se stabilise ou diminue :
- Épuisement des ressources de processeur sur le serveur de base de données
- Épuisement des ressources de processeur sur le client, de sorte que le serveur de base de données ne reçoit plus de travail
- Conflit de verrouillage de base de données
- Temps d'attente d'E/S lorsque la quantité de données dépasse la taille du pool de mémoire tampon Postgres
- Temps d'attente d'E/S imputable à l'utilisation du moteur de stockage
- Goulots d'étranglement de la bande passante réseau renvoyant des données au client
La latence et le débit sont inversement proportionnels. À mesure que la latence augmente, le débit diminue. Cela semble logique. Lorsqu'un goulot d'étranglement commence à se matérialiser, les opérations prennent plus de temps et le système effectue moins d'opérations par seconde.
Le graphique d'évolution de la latence montre comment la latence progresse à mesure que la charge placée sur un système augmente. La latence reste relativement constante, jusqu'à ce que des frictions se produisent en raison d'un conflit de ressources. Le point d'inflexion de cette courbe correspond généralement à l'aplatissement de la courbe de débit dans le graphique d'ajustement du débit.
Un histogramme est également un bon moyen d'évaluer la latence. Dans cette représentation, nous regroupons les latences dans des buckets et comptons le nombre de requêtes qui entrent dans chaque bucket.
Cet histogramme de latence montre que la plupart des requêtes ont une durée inférieure à 100 millisecondes, et que les temps de latence sont supérieurs à 100 millisecondes. Comprendre la cause des requêtes présentant des latences plus longues peut aider à expliquer les variations de performances observées pour l'application. Les causes de la longue traîne d'augmentation des latences correspondent aux latences accrues observées dans le graphique typique d'évolution de la latence et à l'aplatissement du graphique du débit.
L'histogramme de latence est particulièrement utile lorsqu'une application exploite plusieurs modalités. Une modalité est un ensemble normal de conditions de fonctionnement. Par exemple, la plupart du temps, l'application accède à des pages qui se trouvent dans le cache des tampons. La plupart du temps, l'application met à jour les lignes existantes, mais il peut exister plusieurs modes. Parfois, l'application récupère des pages à partir du stockage, insère de nouvelles lignes ou rencontre des conflits de verrouillage.
Lorsqu'une application rencontre ces différents modes de fonctionnement au fil du temps, l'histogramme de latence reflète ces modalités multiples.
Cette figure montre un histogramme bimodal typique où la plupart des requêtes sont traitées en moins de 100 millisecondes, mais où un groupe de requêtes distinct prend entre 401 et 500 millisecondes. Comprendre la cause de cette deuxième modalité peut vous aider à améliorer les performances de votre application. Il peut également y avoir plus de deux modalités.
La deuxième modalité peut être due à des opérations de base de données normales, à une infrastructure et une topologie hétérogènes, ou à un comportement de l'application. Voici quelques exemples à prendre en considération :
- Des accès aux données majoritairement orientés vers un pool de mémoire tampon PostgreSQL, alors que certains visent le stockage
- Une latence réseau vers le serveur de base de données différente pour certains clients
- Une logique d'application qui effectue différentes opérations en fonction de l'entrée ou de l'heure de la journée
- Des conflits de verrouillage sporadiques
- Des pics d'activité client