Der Linux-Kernel bietet eine Vielzahl von Konfigurationsoptionen, die sich auf die Leistung auswirken können. Die Hauptsache ist, die richtige Konfiguration für Ihre Anwendung und Workload auszuwählen. Wie jede andere Datenbank benötigt PostgreSQL eine optimale Optimierung des Linux-Kernels. Falsche Einstellungen können zu einer schlechten Leistung führen. Es ist wichtig, nach jeder Optimierungssitzung eine vergleichende Analyse der Datenbankleistung durchzuführen. In einem meiner vorherigen Beiträge mit dem Titel „Optimieren der Linux-Kernel-Parameter für die PostgreSQL-Optimierung“ habe ich einige der nützlichsten Linux-Kernel-Parameter beschrieben und erläutert, wie sie zur Verbesserung der Datenbankleistung beitragen. Jetzt werde ich die Ergebnisse von Vergleichstests nach der Konfiguration von HugePages unter Linux unter verschiedenen PostgreSQL-Lasten teilen. Ich habe eine vollständige Testsuite unter vielen verschiedenen PostgreSQL-Workloads mit einer unterschiedlichen Anzahl gleichzeitiger Clients durchgeführt.
PC, auf dem die Tests durchgeführt wurden
- Supermicro Server:
- Intel® Xeon® CPU E5-2683 v3 bei 2,00 GHz
- 2 Sockel / 28 Kerne / 56 Gewinde
- Speicher: 256 GB RAM
- Speicher: SAMSUNG SM863 1.9 TB Enterprise SSD
- Dateisystem: ext4 / xfs
- Betriebssystem: Ubuntu 16.04.4, Kernel 4.13.0-36-generic
- PostgreSQL: Version 11
Linux-Kernel-Einstellungen
Ich habe die Standard-Kernel-Parameter ohne Optimierung / Optimierung verwendet, nur Transparent HugePages deaktiviert. Diese Technologie ist standardmäßig aktiviert und weist Seiten mit einer Größe zu, die für die Verwendung mit Datenbanken nicht empfohlen wird. Im Allgemeinen benötigen Datenbanken HugePages mit fester Größe, Transparente HugePages können diese jedoch nicht bereitstellen. Daher wird immer empfohlen, diese Funktion zu deaktivieren und standardmäßig klassische HugePages zu installieren.
PostgreSQL-Einstellungen
Ich habe für alle Tests dieselben PostgreSQL-Einstellungen verwendet, um verschiedene PostgreSQL-Workloads mit unterschiedlichen Linux HugePages-Einstellungen aufzuzeichnen. Für alle Tests wurden die folgenden PostgreSQL-Einstellungen angewendet:
shared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON'
Testschema
Das Testschema spielt eine wichtige Rolle. Alle Tests werden dreimal durchgeführt, die Dauer jedes Laufs beträgt 30 Minuten. Basierend auf den Ergebnissen dieser 3 Tests habe ich den Durchschnittswert abgeleitet. Die Tests wurden mit dem PostgreSQL-Tool pgbench durchgeführt . Es arbeitet mit einem Skalierungsfaktor in Schritten von ca. 16 MB Last.
Riesenseiten
Standardmäßig verwendet Linux 4K-Speicherseiten sowie die HugePages-Technologie. BSD verwendet die Super Pages-Technologie und Windows verwendet Large Pages. PostgreSQL unterstützt nur die HugePages (Linux) -Technologie. In Fällen, in denen viel Speicher verwendet wird, verringern kleinere Seiten die Leistung. Mit HugePages erhöhen Sie den zugewiesenen Speicher für die Anwendung und reduzieren daher den "Overhead", der während des Zuweisungs- / Auslagerungsprozesses auftritt. Somit steigern HugePages die Produktivität.
Hier sind die Einstellungen für HugePages mit einer Größe von 1 GB. Diese Informationen sind jederzeit über / proc verfügbar.
AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Ich habe in einem früheren Beitrag mehr über HugePages geschrieben.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/
Im Allgemeinen sind HugePages 2 MB und 1 GB groß, daher ist es sinnvoll, 1 GB zu verwenden.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/
Testergebnisse
Dieser Test zeigt den Gesamteffekt der Verwendung von HugePages verschiedener Größen. Die erste Testsuite wurde mit einer Seitengröße von 4 KB erstellt - standardmäßig unter Linux verwendet - und ohne Aktivierung von HugePages. Ich möchte Sie daran erinnern, dass ich die Option Transparente HugePages für die gesamte Dauer der Tests deaktiviert habe.
Dann wurde eine zweite Reihe von Tests für HugePages mit einer Größe von 2 MB durchgeführt. Schließlich wurde ein dritter Satz von Tests für 1 GB HugePages durchgeführt.
Für alle Vergleichstests wurde PostgreSQL DBMS 11 verwendet. Die Kits enthalten Kombinationen verschiedener Datenbankgrößen und verschiedener Clients. Die folgende Grafik zeigt die Ergebnisse eines Leistungsvergleichs unter Verwendung dieser Tests: TPS (Anzahl der Transaktionen pro Sekunde) - entlang der Y-Achse und die Datenbankgröße und die Anzahl der Clients für eine Datenbank einer bestimmten Größe - entlang der X-Achse.
Aus dem obigen Diagramm ist ersichtlich, dass durch die Verwendung von HugePages der Gewinn mit zunehmender Anzahl von Kunden und der Größe der Datenbank zunimmt, solange diese Größe innerhalb des vorab zugewiesenen gemeinsam genutzten Puffers bleibt.
Dieser Test verglich TPS und die Anzahl der Kunden. In diesem Fall beträgt die Datenbankgröße 48 GB. Die Y-Achse zeigt TPS und die X-Achse zeigt die Anzahl der verbundenen Clients. Die Datenbankgröße ist klein genug, um in einen gemeinsam genutzten Puffer mit einer festen Größe von 64 GB zu passen.
Wenn HugePages 1 GB groß ist, steigt der vergleichbare Leistungsgewinn mit der Anzahl der Kunden.
Das nächste Diagramm ist das gleiche wie das vorherige, die Datenbankgröße beträgt jedoch 96 GB. Dies ist größer als die feste Gesamtpuffergröße von 64 GB.
Das Wichtigste dabei: Die Leistung mit HugePages von 1 GB steigt mit zunehmender Anzahl von Kunden und bietet letztendlich eine bessere Leistung als die Verwendung von HugePages mit 2 MB oder Standard-4-KB-Seiten.
Dieser Test zeigt das Verhältnis von TPS zur Datenbankgröße. In diesem Fall beträgt die Anzahl der verbundenen Clients 32. Auf der Y-Achse wird TPS und auf der X-Achse die Datenbankgröße angezeigt.
Wenn die Größe der Datenbank die Größe der vorab zugewiesenen HugePages überschreitet, wird die Leistung erwartungsgemäß erheblich reduziert.
Fazit
Eine meiner Hauptempfehlungen ist das Deaktivieren von Transparent HugePages. Sie erhalten die größte Leistungssteigerung, wenn die Datenbank in einem gemeinsam genutzten Puffer mit aktivierten HugePages abgelegt wird. Die optimale Größe von HugePages wird durch Versuch und Irrtum bestimmt. Dieser Ansatz kann jedoch möglicherweise zu einem erheblichen Gewinn an TPS führen, wenn die Datenbankgröße groß genug ist, gleichzeitig aber in einen gemeinsamen Puffer passt.