In diesem Dokument wird beschrieben, wie Sie die Leistungsergebnisse in AlloyDB Omni auf einer VM auswerten. In diesem Dokument wird davon ausgegangen, dass Sie mit PostgreSQL vertraut sind.
Wenn Sie den Durchsatz im Zeitverlauf grafisch darstellen, während eine andere Variable geändert wird, steigt der Durchsatz in der Regel, bis die Ressourcen erschöpft sind.
Die folgende Abbildung zeigt ein typisches Diagramm zur Durchsatzskalierung. Mit zunehmender Anzahl der Clients steigen Arbeitslast und Durchsatz, bis alle Ressourcen ausgeschöpft sind.
Idealerweise sollte sich der Durchsatz verdoppeln, wenn Sie die Auslastung des Systems verdoppeln. In der Praxis kommt es zu Ressourcenkonflikten, die zu geringeren Durchsatzsteigerungen führen. Irgendwann führt die Ressourcenausschöpfung oder -konflikte dazu, dass der Durchsatz stagniert oder sogar sinkt. Wenn Sie den Durchsatz optimieren, ist dies ein wichtiger Punkt, da Sie so herausfinden können, wo Sie die Anwendung oder das Datenbanksystem optimieren müssen, um den Durchsatz zu verbessern.
Typische Gründe für einen stagnierenden oder sinkenden Durchsatz sind:
- Ausschöpfung der CPU-Ressourcen auf dem Datenbankserver
- Ausschöpfung der CPU-Ressourcen auf dem Client, sodass dem Datenbankserver keine weiteren Aufgaben gesendet werden
- Datenbanksperrenkonflikt
- Wartezeit für die E/A, wenn die Daten die Größe des Postgres-Pufferpools überschreiten
- Wartezeit für I/O aufgrund der Auslastung der Speicher-Engine
- Engpässe bei der Netzwerkbandbreite, die die Rückgabe von Daten an den Client beeinträchtigen
Latenz und Durchsatz sind umgekehrt proportional. Je höher die Latenz, desto niedriger ist der Durchsatz. Intuitiv ergibt das Sinn. Wenn sich ein Engpass abzeichnet, dauern die Vorgänge länger und das System führt weniger Vorgänge pro Sekunde aus.
In der Grafik zur Latenzskalierung sehen Sie, wie sich die Latenz ändert, wenn die Auslastung eines Systems zunimmt. Die Latenz bleibt relativ konstant, bis es aufgrund von Ressourcenkonflikten zu Problemen kommt. Der Wendepunkt dieser Kurve entspricht in der Regel der Abflachung der Durchsatzkurve im Diagramm zur Durchsatzskalierung.
Eine weitere nützliche Möglichkeit zur Auswertung der Latenz ist ein Histogramm. Bei dieser Darstellung werden Latenzen in Buckets gruppiert und gezählt, wie viele Anfragen in jeden Bucket fallen.
Dieses Histogramm für die Latenz zeigt, dass die meisten Anfragen weniger als 100 Millisekunden dauern und welche Latenzen länger als 100 Millisekunden sind. Wenn Sie die Ursache für die Anfragen mit längeren Latenzzeiten kennen, können Sie die Abweichungen bei der Anwendungsleistung besser nachvollziehen. Die Ursachen für den langen Schwanz der erhöhten Latenzen entsprechen den erhöhten Latenzen in der typischen Grafik zur Latenzskalierung und der Abflachung der Durchsatzgrafik.
Das Histogramm der Latenz ist am nützlichsten, wenn eine Anwendung mehrere Modalitäten hat. Eine Modalität ist eine normale Betriebsbedingung. Beispielsweise greift die Anwendung die meiste Zeit auf Seiten zu, die sich im Puffercache befinden. In den meisten Fällen aktualisiert die Anwendung vorhandene Zeilen. Es kann jedoch mehrere Modi geben. Manchmal ruft die Anwendung Seiten aus dem Speicher ab, fügt neue Zeilen ein oder es kommt zu Sperrkonflikten.
Wenn eine Anwendung im Laufe der Zeit diese verschiedenen Betriebsmodi aufweist, werden diese verschiedenen Modalitäten im Histogramm der Latenz angezeigt.
Diese Abbildung zeigt ein typisches bimodales Histogramm, bei dem die meisten Anfragen in weniger als 100 Millisekunden verarbeitet werden, es gibt aber einen weiteren Cluster von Anfragen, der 401–500 Millisekunden in Anspruch nimmt. Wenn Sie die Ursache dieser zweiten Modalität kennen, können Sie die Leistung Ihrer Anwendung verbessern. Es können auch mehr als zwei Modalitäten vorhanden sein.
Die zweite Modalität kann auf normale Datenbankvorgänge, heterogene Infrastruktur und Topologie oder Anwendungsverhalten zurückzuführen sein. Beispiele:
- Die meisten Datenzugriffe erfolgen über den PostgreSQL-Pufferpool, einige aber auch über den Speicher.
- Unterschiede bei den Netzwerklatenzen einiger Clients zum Datenbankserver
- Anwendungslogik, die je nach Eingabe oder Uhrzeit unterschiedliche Vorgänge ausführt
- Sporadischer Sperrenkonflikt
- Spitzen bei den Kundenaktivitäten