Der Linux-Kernel bietet eine Vielzahl von Konfigurationsoptionen, die sich auf die Leistung auswirken können. Es geht darum, die richtige Konfiguration für Ihre Anwendung und Arbeitslast zu erhalten. Wie jede andere Datenbank verwendet PostgreSQL den Linux-Kernel für eine optimale Konfiguration. Schlecht eingestellte Einstellungen können zu einer schlechten Leistung führen. Daher ist es wichtig, dass Sie die Datenbankleistung nach jeder Optimierungssitzung messen, um Leistungseinbußen zu vermeiden. In einer meiner früheren Veröffentlichungen, „Optimieren von Linux-Kernel-Parametern für die PostgreSQL-Optimierung“, habe ich einige der nützlichsten Linux-Kernel-Parameter beschrieben und erläutert, wie sie Ihnen bei der Verbesserung der Datenbankleistung helfen können. Jetzt werde ich meine Testergebnisse teilen, nachdem ich große Linux-Seiten mit einer anderen PostgreSQL-Workload eingerichtet habe. Ich habe eine Reihe von Tests für verschiedene PostgreSQL-Lastgrößen und die gleichzeitige Anzahl von Clients durchgeführt.
Prüfmaschine
- 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-Einstellungen ohne Optimierung / Optimierung verwendet, außer durch Deaktivieren transparenter großer Seiten (Transparent HugePages). Transparente große Seiten sind standardmäßig aktiviert und markieren die Seitengröße, die für die Verwendung durch die Datenbank möglicherweise nicht empfohlen wird. Datenbanken erfordern normalerweise große Seiten mit fester Größe, die nicht von transparenten großen Seiten abgedeckt werden. Daher wird immer empfohlen, diese Funktion zu deaktivieren und standardmäßig klassische große Seiten zu verwenden.
PostgreSQL-Einstellungen
Ich habe die einheitlichen PostgreSQL-Einstellungen für alle Tests verwendet, um verschiedene PostgreSQL-Workloads mit unterschiedlichen Einstellungen für große Linux-Seiten aufzuzeichnen. Hier ist das PostgreSQL-Setup, das für alle Tests verwendet wird:
postgresql.confshared_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
Beim Testen spielt das Testschema eine wichtige Rolle. Alle Tests werden für jeden Lauf dreimal 30 Minuten lang durchgeführt. Ich habe den Durchschnitt dieser drei Indikatoren genommen. Die Tests wurden mit dem Leistungstest-Tool PostgreSQL
pgbench durchgeführt . pgbench arbeitet mit einem Skalierungsfaktor mit einem Skalierungsfaktor von ungefähr 16 MB Arbeitslast.
Große Seiten (HugePages)
Linux verwendet standardmäßig 4K-Speicherseiten zusammen mit großen Seiten. BSD hat Superseiten, während Windows große Seiten hat. PostgreSQL unterstützt nur große Seiten (Linux). Bei hoher Speichernutzung verringern kleine Seiten die Leistung. Durch die Installation großer Seiten erhöhen Sie den zugewiesenen Speicher für die Anwendung und reduzieren folglich die Betriebskosten, die während der Zuweisung / des Austauschs entstehen. Das heißt, Sie steigern die Produktivität mit großen Seiten.
Hier ist das Setup für große Seiten bei Verwendung einer großen Seitengröße von 1 GB. Sie können diese Informationen jederzeit von / proc erhalten.
$ cat / proc / meminfo | grep -i riesig AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB
Weitere Informationen zu großen Seiten finden Sie in meinem vorherigen Blogbeitrag.
https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/In der Regel sind große Seiten 2 MB und 1 GB groß. Daher ist es sinnvoll, eine Größe von 1 GB anstelle einer viel kleineren Größe von 2 MB zu verwenden.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhugehttps://kerneltalks.com/services/what-is-huge-pages-in-linux/Testergebnisse
Dieser Test zeigt den Gesamteffekt verschiedener Größen großer Seiten. Die erste Testsuite wurde mit der Standardseitengröße unter Linux 4K ohne große Seiten erstellt. Beachten Sie, dass transparente große Seiten ebenfalls deaktiviert wurden und während all dieser Tests deaktiviert blieben.
Dann wurde der zweite Satz von Tests auf großen Seiten von 2 MB durchgeführt. Schließlich wird der dritte Testsatz mit großen Seiten von 1 GB ausgeführt.
Alle diese Tests wurden in PostgreSQL Version 11 durchgeführt. Die Sets enthalten eine Kombination verschiedener Größen der Datenbank und der Clients. Die folgende Grafik zeigt die vergleichenden Leistungsergebnisse für diese Tests mit TPS (Transaktionen pro Sekunde) auf der Y-Achse, Datenbankgröße und Anzahl der Clients pro Datenbankgröße auf der X-Achse.
Aus dem obigen Diagramm ist ersichtlich, dass der Leistungsgewinn bei großen Seiten mit der Anzahl der Clients und der Größe der Datenbank zunimmt, wenn die Größe im zuvor zugewiesenen Puffer im gemeinsam genutzten Speicher verbleibt.
Dieser Test zeigt TPS im Vergleich zur Anzahl der Clients. In diesem Fall beträgt die Datenbankgröße 48 GB. Auf der Y-Achse haben wir TPS und auf der X-Achse haben wir die Anzahl der verbundenen Clients. Die Datenbankgröße ist klein genug, um in einen gemeinsam genutzten Puffer zu passen, der auf 64 GB festgelegt ist.
Wenn große Seiten auf 1 GB festgelegt sind, ist der relative Leistungsgewinn umso höher, je mehr Clients vorhanden sind.
Das folgende Diagramm ist bis auf die Datenbankgröße von 96 GB das gleiche wie oben. Dies überschreitet die Größe des gemeinsam genutzten Puffers, der auf 64 GB festgelegt ist.
Die wichtigste Beobachtung hierbei ist, dass die Leistung mit großen Seiten von 1 GB mit zunehmender Anzahl von Clients zunimmt und letztendlich mehr Leistung bietet als große Seiten mit 2 MB oder die Standardseitengröße von 4 KB.
Dieser Test zeigt TPS abhängig von der Größe der Datenbank. In diesem Fall beträgt die Anzahl der verbundenen Clients 32. Auf der Y-Achse haben wir TPS und auf der X-Achse die Datenbankgrößen.
Wenn die Datenbank über die vorab zugewiesenen großen Seiten hinausgeht, wird die Leistung erwartungsgemäß erheblich reduziert.
Zusammenfassung
Eine meiner wichtigsten Empfehlungen ist, dass wir Transparent HugePages deaktivieren sollten. Sie werden den größten Leistungsgewinn sehen, wenn die Datenbank in einem gemeinsam genutzten Puffer mit aktivierten großen Seiten abgelegt wird. Die Auswahl der Größe großer Seiten erfordert einen geringen Aufwand an Versuchen und Irrtümern. Dies kann jedoch möglicherweise zu einer signifikanten Erhöhung des TPS führen, wenn die Datenbankgröße groß ist, aber klein genug bleibt, um in einen gemeinsam genutzten Puffer zu passen.