PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Benchmarking der PostgreSQL-Leistung

Der Zweck des Benchmarking einer Datenbank besteht nicht nur darin, die Leistungsfähigkeit der Datenbank zu überprüfen, sondern auch das Verhalten einer bestimmten Datenbank gegenüber Ihrer Anwendung. Unterschiedliche Hardware liefert unterschiedliche Ergebnisse basierend auf dem von Ihnen festgelegten Benchmarking-Plan. Es ist sehr wichtig, den Server (den eigentlichen Benchmarking-Server) von anderen Elementen wie den Servern, die die Last steuern, oder den Servern, die zum Sammeln und Speichern von Leistungsmetriken verwendet werden, zu isolieren. Als Teil der Benchmarking-Übung müssen Sie die Anwendungsmerkmale wie a) abrufen. Ist die Anwendung lese- oder schreibintensiv? oder b) Wie ist die Lese-/Schreibaufteilung (z. B. 80:20)? oder c) Wie groß ist der Datensatz? Sind die Daten und die Struktur repräsentativ für die tatsächliche Produktionsdatenbank usw.

PostgreSQL ist die weltweit fortschrittlichste Open-Source-Datenbank. Wenn ein RDBMS-Unternehmenskunde seine Datenbank auf Open Source migrieren möchte, wäre PostgreSQL die erste zu prüfende Option.

Dieser Beitrag behandelt Folgendes:

  • Benchmarking von PostgreSQL
  • Was sind die wichtigsten Leistungsfaktoren in PostgreSQL
  • Welche Hebel können Sie ziehen, um die Leistung zu steigern
  • Welche Performance-Fallen gilt es zu vermeiden
  • Was sind häufige Fehler, die Menschen machen?
  • Woher wissen Sie, ob Ihr System funktioniert? Welche Tools können Sie verwenden?

Benchmarking von PostgreSQL

Das Standardtool zum Benchmarking von PostgreSQL ist pgbench. Standardmäßig basieren pgbench-Tests auf TPC-B. Es umfasst 5 SELECT-, INSERT- und UPDATE-Befehle pro Transaktion. Abhängig von Ihrem Anwendungsverhalten können Sie jedoch eigene Skriptdateien schreiben. Lassen Sie uns einen Blick auf die Standard- und einige skriptorientierte Testergebnisse werfen. Wir werden für diese Tests die neueste Version von PostgreSQL verwenden, zum Zeitpunkt der Erstellung dieses Artikels PostgreSQL 10. Sie können es mit ClusterControl oder den Anweisungen hier installieren:https://www.openscg.com/bigsql/package-manager/.

Maschinenspezifikationen

Version:RHEL 6 – 64 Bit
Speicher:4 GB
Prozessoren:4
Speicher:50 GB
PostgreSQL-Version:10.0
Datenbankgröße:15 GB

Bevor Sie das Benchmarking mit dem pgbench-Tool ausführen, müssen Sie es mit dem folgenden Befehl initialisieren:

-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.

Wie in den NOTICE-Meldungen gezeigt, erstellt es die Tabellen pgbench_history, pgbench_tellers, pgbench_accounts und pgbench_branches, um die Transaktionen für das Benchmarking auszuführen.

Hier ist ein einfacher Test mit 10 Clients:

-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)

Wie Sie sehen, lief es mit 10 Clients und 10 Transaktionen pro Client. Es gab Ihnen 739 Transaktionen/Sek.Es gab Ihnen 739 Transaktionen/Sek. Wenn Sie es für eine bestimmte Zeit ausführen möchten, können Sie die Option "-T" verwenden. Im Allgemeinen ist ein 15- oder 30-minütiger Lauf ausreichend.

Bis jetzt haben wir darüber gesprochen, wie pgbench ausgeführt wird, jedoch nicht darüber, was Optionen sein sollten. Bevor Sie mit dem Benchmarking beginnen, sollten Sie die richtigen Details vom Anwendungsteam erhalten unter:

  • Welche Art von Arbeitsbelastung?
  • Wie viele gleichzeitige Sitzungen?
  • Was ist die durchschnittliche Ergebnismenge von Abfragen?
  • Was sind die erwarteten tps (Transaktion pro Sekunde)?

Hier ist ein Beispiel für schreibgeschützte Workloads. Sie können die Option "-S" verwenden, um nur SELECTs zu verwenden, die unter schreibgeschützt fallen. Beachten Sie, dass -n das Vakuumieren von Tabellen überspringen soll.

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$

Die Latenz ist hier die durchschnittlich verstrichene Transaktionszeit jeder von jedem Client ausgeführten Anweisung. Es gibt 52 tps mit der gegebenen Hardware. Da dieser Benchmark für eine schreibgeschützte Umgebung gilt, versuchen wir, die Parameter shared_buffers und Effective_cache_size in der Datei postgresql.conf zu optimieren und die tps-Anzahl zu überprüfen. Sie sind im obigen Test auf Standardwerten, versuchen Sie, die Werte zu erhöhen, und überprüfen Sie die Ergebnisse.

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)

Das Ändern der Parameter verbesserte die Leistung um 30 %.

pgbench führt normalerweise Transaktionen auf seinen eigenen Tabellen aus. Wenn Sie eine Arbeitslast von 50 % Lese- und 50 % Schreibvorgänge haben (oder eine 60:40-Umgebung), können Sie eine Skriptdatei mit einer Reihe von Anweisungen erstellen, um die erwartete Arbeitslast zu erreichen.

-bash-4.1$ cat /tmp/bench.sql 
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql 
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
 - weight: 1 (targets 50.0% of total)
 - 12707 transactions (50.0% of total, tps = 42.225555)
 - latency average = 914.240 ms
 - latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
 - weight: 1 (targets 50.0% of total)
 - 12729 transactions (50.0% of total, tps = 42.298662)
 - latency average = 1446.721 ms
 - latency stddev = 765.933 ms
Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter

Was sind die wichtigsten Leistungsfaktoren in PostgreSQL

Betrachten wir eine reale Produktionsumgebung, wird diese mit verschiedenen Komponenten auf Anwendungsebene, Hardware wie CPU und Speicher und dem zugrunde liegenden Betriebssystem konsolidiert. Wir installieren PostgreSQL auf dem Betriebssystem, um mit anderen Komponenten der Produktionsumgebung zu kommunizieren. Jede Umgebung ist anders und die Gesamtleistung wird beeinträchtigt, wenn sie nicht richtig konfiguriert ist. In PostgreSQL laufen einige Abfragen schneller und andere langsamer, dies hängt jedoch von der eingestellten Konfiguration ab. Das Ziel der Optimierung der Datenbankleistung besteht darin, den Datenbankdurchsatz zu maximieren und die Verbindungen zu minimieren, um den größtmöglichen Durchsatz zu erreichen. Nachfolgend sind einige wichtige Leistungsfaktoren aufgeführt, die sich auf die Datenbank auswirken:

  • Arbeitsbelastung
  • Ressource
  • Optimierung
  • Kontroverse

Die Arbeitslast besteht aus Batch-Jobs, dynamischen Abfragen für Online-Transaktionen und Datenanalyseabfragen, die zum Generieren von Berichten verwendet werden. Die Arbeitsbelastung kann während des Tages, der Woche oder des Monats unterschiedlich sein und hängt von den Anwendungen ab. Die Optimierung jeder Datenbank ist einzigartig. Dies kann eine Konfiguration auf Datenbankebene oder eine Optimierung auf Abfrageebene sein. Wir werden in weiteren Abschnitten des Beitrags mehr über die Optimierung erfahren. Konflikt ist der Zustand, in dem zwei oder mehr Komponenten der Arbeitslast versuchen, eine einzelne Ressource auf widersprüchliche Weise zu verwenden. Mit zunehmender Konkurrenz sinkt der Durchsatz.

Was sind Tipps und Best Practices

Hier sind einige Tipps und Best Practices, die Sie befolgen können, um Leistungsprobleme zu vermeiden:

  • Sie können Wartungsaktivitäten wie VACUUM und ANALYZE nach einer großen Änderung in Ihrer Datenbank ausführen. Dies hilft dem Planer, den besten Plan für die Ausführung von Abfragen zu entwickeln.
  • Suchen Sie nach Notwendigkeit, Tabellen zu indizieren. Dadurch werden Abfragen viel schneller ausgeführt, anstatt vollständige Tabellenscans durchführen zu müssen.
  • Um einen Indexdurchlauf viel schneller zu machen, können Sie CREATE TABLE AS- oder CLUSTER-Befehle verwenden, um Zeilen mit ähnlichen Schlüsselwerten zu gruppieren.
  • Wenn Sie ein Leistungsproblem sehen, verwenden Sie den EXPLAIN-Befehl, um sich den Plan anzusehen, wie der Optimierer entschieden hat, Ihre Abfrage auszuführen.
  • Sie können versuchen, die Pläne zu ändern, indem Sie den Optimierer beeinflussen, indem Sie Abfrageoperatoren ändern. Wenn Sie beispielsweise einen sequentiellen Scan für Ihre Abfrage sehen, können Sie den Seq-Scan mit "SET ENABLE_SEQSCAN TO OFF" deaktivieren. Es gibt keine Garantie dafür, dass der Optimierer diesen Operator nicht wählt, wenn Sie ihn deaktivieren. Der Optimierer hält den Betreiber lediglich für viel teurer. Weitere Details finden Sie hier:https://www.postgresql.org/docs/current/static/runtime-config-query.html
  • Sie können auch versuchen, die Kostenparameter wie CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST und EFFECTIVE_CACHE_SIZE zu ändern, um den Optimierer zu beeinflussen. Weitere Details finden Sie hier:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
  • Filtern Sie Daten immer auf dem Server und nicht in der Client-Anwendung. Dadurch wird der Netzwerkverkehr minimiert und die Leistung verbessert.
  • Um allgemeine Operationen auszuführen, wird immer empfohlen, serverseitige Prozeduren (Trigger und Funktionen) zu verwenden. Serverseitige Trigger oder Funktionen werden bei ihrer ersten Verwendung geparst, geplant und optimiert, nicht jedes Mal.

Was sind häufige Fehler, die Menschen machen

Einer der häufigsten Fehler ist, den Datenbankserver und die Datenbank mit Standardparametern auszuführen. Die PostgreSQL-Standardkonfiguration wurde in wenigen Umgebungen getestet, aber nicht jede Anwendung würde diese Werte optimal finden. Sie müssen also Ihr Anwendungsverhalten verstehen und darauf basierend Ihre Konfigurationsparameter festlegen. Sie können das pgTune-Tool verwenden, um Werte für Ihre Parameter basierend auf der von Ihnen verwendeten Hardware zu erhalten. Sie können einen Blick auf http://pgtune.leopard.in.ua/ werfen. Denken Sie jedoch daran, dass Sie Ihre Anwendung mit den von Ihnen vorgenommenen Änderungen testen müssen, um festzustellen, ob die Änderungen zu Leistungseinbußen führen.

Eine weitere zu berücksichtigende Sache wäre die Indizierung der Datenbank. Indizes helfen, die Daten schneller abzurufen, aber mehr Indizes verursachen Probleme beim Laden der Daten. Überprüfen Sie also immer, ob es in der Datenbank ungenutzte Indizes gibt, und entfernen Sie diese, um die Wartung dieser Indizes zu reduzieren und das Laden von Daten zu verbessern.