My.cnf to postgresql.conf conversion

Hallo liebes pg-forum,
zunächst möchte ich mitteilen, dass ich mir nicht sicher bin, ob dieser Thread unter “Installation” oder “Konfiguration” erstellt werden sollte. Also falsch ich es falsch gepostet habe, bitte verschieben. Danke.

Meine Fragen lauten wie folgt: Kann man eine MySQL “my.cnf” file zu einer “postgresql.conf” konvertieren? Bzw. gibt es mittlerweile ein Tool oder Ähnliches dafür?
Ich möchte meine optimierte MySQL Konfigurationen behalten bzw. übernehmen beim Wechsel of PostgreSQL. Leider sind die Variablennamen etc. ja nicht 1 zu 1 gleich, deshalb bräuchte ich Hilfe. Auch wenn es kein Script/Programm dafür gibt es automatisiert auszuführen, gibt es eventuell eine Dokumentation oder Ähnliches die, die Konfigurationsunterschiede bzw. -gemeinsamkeiten/ähnlichkeiten zumindest “sinngemäß” oder “teilweise” erklärt (z.B. “‘innodb_log_file_size’ in MySQL enstpricht ‘X’ in PostgreSQL”), so dass ich die Änderungen (in der postgresql.conf) manuell vornehmen könnte.

Das einzig ähnliche Thema habe ich auf der offizielen PostgreSQL-Webseiten finden können, aber es ist aus dem Jahre 2002 (https://www.postgresql.org/message-id/1036102643.3122.73.camel%40oc). Sehr wahrscheinlich hat sich sehr vieles seit dem verändert :). Auch per Google habe ich nichts finden können. Deshalb erhoffe ich mir hier geholfen zu werden.
Vielen Dank für jegliche Mühen im Voraus.

Nein, das kann man nicht so einfach konvertieren. PostgreSQL arbeitet komplett anders als MySQL (es funktioniert, mal so als einer der wesentlichen Unterschiede…).

Wichtige Parameter sind shared_buffers, Faustregel 25% vom RAM. Die anderen Parameter hängen sehr, sehr von der Anwendung ab. Du kannst hier fragen, wenn Dir Dinge nicht klar sind. Zu einigen Parametern findest Du im Blog bei uns (2ndQ) auch diverse Beiträge.

Grundsätzlich hat ja @akretschmer schon gesagt, dass eine 1:1 “Konvertierung” nicht geht (und auch nicht sinnvoll ist)

Ich würde erst mal mit den Default-Einstellungen anfangen. Die decken schon einen recht großen Einsatzbereich ab.

Für den Anfang reicht in den allermeisten Fällen die Anpassung von shared_buffers und work_mem.

Alle anderen Einstellungen fasst man eigentlich erst an, wenn man damit konkret Probleme angehen möchte.

Danke für Eure Antworten.
Schade, dass das nicht so einfach geht :(.
Da ich eine getweakedte MySQL config habe, wäre es wahrscheinlich nicht sinnvoll eine “Default” PG config zu benutzen. Was wären denn die wichtigsten Anpassungen bei PG (bin kein DBS-Laie, sondern nur PG-Laie, ansonsten benutze ich MySQL & MariaDB schon über 10 Jahre)?
Mein System hat so gut wie keine Schreibvorgänge, sondern überwiegend Lesevorgänge (Selects und updates). Was wären da so die Parameter, die man anpassen sollte (und wie hoch bzw. niedrig im Bezug auf RAM, CPU & SSD)?
Mir reichen auch Links, aber wäre super falls Ihr zu dem aus Erfahrungen sprechen könntet.

Die Frage ist: welche Gründe gab es für die Anpassungen in MySQL und welche Probleme wurden dadurch behoben.

  • wie viel RAM?
  • wie viele gleichzeitige User?
  • wie groß ist die DB?
  • welche PG-Version?
  • welches OS?
  • was für Hardware (Platten etc.)?
  • ist das ein nur für PG dedizierter Server?

Updates sind übrigens Schreibvorgänge.

Ach so, stimmt… habe ich vergessen zu erwähnen: Viele Select-Abfragen und einige von denen sind ähnliche bzw. immer wieder mal vorkommende Abfragen, also haben wir die Performanz und Geschwindigkeit geändert für z.B. Cache und/oder bufferpoolsize usw.
Auf den Server greifen nicht viele Personen zu, sondern im Schnitt gerade mal 50 Personen. Einzelne Abfragen dürfen also nicht zu lange dauern, da wir mit diesen Personen täglich persönlichen Kontakt haben und die dann ziemlich schnell genervt rüberkommen und Ihre “Meinung” kundtun (haha).

RAM: 32GB
Gleichzeitige User: Max. 20
DB: 260+GB
PG-Version: Aktuellste (12?)
OS: Linux
Hardware: CPU: Intel Dualcore, SSD 512GB
Auf dem Server laufen auch andere Dinge außer dem PG

generell gilt: Du kannst mit guter/schlechter Config vielleicht im Bereich von 5-10% die Performance beeinflussen. Dinge wie fehlende Indexe, zu viele Indexe, kapotte DB-Struktur, kapotte Abfragen etc. beeinflussen das sehr, sehr viel mehr.

Beschäftige Dich mit Explain, logge vernünftig (hier ist die Default-Config nicht sehr gut), nutze Extensions wie pg_stat_statements um Performance-Probleme zu erkennen.

Da die Indexe, Struktur und Abfragen ja aus der bisherigen optimierten MySQL kommen, würde ich mich gerne auf die PG config konzentrieren (das wären ja dann die “übrigen 5-10%”) :slight_smile:.

Das ist ja das Problem, daß das aus MySQL kommt:

  • MySQL hat deutlich weniger Datentypen
  • MySQL hat deutlich weniger Indexmöglichkeiten
  • MySQL hat erhebliche Mängel was SQL-Features betrifft

In Summe: man sollte mal einen Blick auch und gerade auf diese Dinge werfen.

Oh… wie sollte ich denn da am besten Vorgehen?

PS: Dennoch kann es ja trotzdem sein, dass keine Änderungen an Datentypen usw. vorgenommen werden müssen.

schrieb ich schon, logge lahme Abfragen (log_min_duration_statement, pg_stat_statements) und schaue Dir die EXPLAIN ANALYSE - Pläne an. Dazu beschäftige Dich mit den ganzen Indexmöglichkeiten (Btree, Gin, GiST, partielle Indexe, funktionale Indexe etc.) und schau, was Du da nutzen kannst.

Das ist ein weites Feld …

Okay, danke. Werde ich tun.

Eine letzte Frage für heute: Gibt es eigentlich so (https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/) etwas ähnliches auch für PG? Also ein How-to bzw. um bei dem verlinkten Wortlaut zu bleiben: “10 postgreSQL performance tuning settings after installation”
Wenn, ja bitte verlinken (egal ob hier vom/im Forum oder außerhalb).

es gibt einige Tools, aber ich halte davon nicht sehr viel.

Wir haben, wenn wir für neue Kunden Onboarding machen, einen DataCollector. Basierend aus dessen gesammelten Daten geben wir Hinweise zur Optimierung. Das ist dann schon etwas tiefgehender, weil das dann auch interne Statistiken der DB mit auswertet.

Kannst ja Kunde werden :wink:

Haha danke, aber kein Interesse.
Ja, auch ich finde die meisten der Tools unnütz, aber darauf wollte ich nicht hinaus. Sondern allgemeine Faustregeln bzw. Erfahrungen die sich bewährt haben, so dass sie auch in der Allgemeinheit anerkannt wurden und praktiziert werden (denn die Default-Configs sind so gut wie nie “ready to go” ohne jegliche Anpassungen). Z.B. in gängigen/bekannten Blogs/Wissenschaftseiten beschrieben. Der Link ist von Percona (sollte bekannt sein).
Die Frage also: Gibt es so etwas ähnliches für pg?

die Default-Config von PG funktioniert immer, nur ist sie sehr konservativ. Shared_buffers wurde genannt. Work_mem kann man (vorsichtig) erhöhen, hängt aber auch von der Anzahl gleichzeitiger Verbindungen ab. Übertreibt man es, hat man OOM-Kills. Dazu auch immer mit explain analyse arbeiten. Vacuum-Settings sind auch sehr konservativ, wenn Du aber eher wenig Schreiblast hast dann reichen die so. checkpoint_completion_target empfehlen wir 0.9, dazu erhöhen von checkpoint_timeout. Bei SSD’s random_page_cost runter setzen.

Viel mehr braucht man am Anfang nicht zu machen, man beobachtet das ganze im Betrieb und fragt dann uns - sofern man Kunde ist :wink:

Danke.
Ich kann nicht Kunde werden, wenn ich selber im Kundenauftrag handle :wink:.
Aber vielleicht leite ich den Kunden mal in Zukunft weiter an Sie (sofern bzw. falls dann “neue” issues anstehen sollten) :sweat_smile:.

ja, gerne.

Der schon genannte DataCollector und deren Auswertung beim Onboarding soll übrigens dabei helfen, issues vorausschauend zu vermeiden. Das ist unser eigentliches Ziel bei Supportverträgen. Dein Kunde kann mich gern und unverbindlich kontaktieren.

Ein Dual-Core (selbst mit Hyperthreading) ist natürlich ziemlich low-end für einen Datenbank Server (speziell wenn da noch andere Sachen drauf laufen). Da hat ja mein Mittelklasse Handy mehr zu bieten.

Ansonsten würde ich bei der Hardware Ausstattung mal mit diesen Einstellungen anfangen:

effective_cache_size = 8GB
shared_buffers = 4GB
work_mem = 16MB
random_page_cost = 1.5
jit = off

Beachte das “effective_cache_size” keine Speicher reserviert, sondern nur als Anhaltspunkt für den Optimizer dient, wie wahrscheinlich Daten im Cache liegen werden.

Ansonsten verwende ich noch gerne folgende Einstellungen:

track_io_timing = on
track_activities = on
log_hostname = on

Wenn das eine gute (“Enterprise Grade”) SSD ist, dann kann man auch noch überlegen ob man effective_io_concurrency hoch setzt. Als Startwert könnte man mal mit 10 anfangen. Aber letztendlich hilft das nur wenn man viele gleichzeitige Abfragen hat, aber mit nur 2/4 Prozessoren ist da sowieso sehr schnell Schluss mit parallelen Anfragen.

Um das System nicht zu überlasten, würde ich vielleicht auch noch Parallel Queries einschränken und max_parallel_workers auf 4 oder sogar nur 2 reduzieren.

Danke für die Rückmeldung.

Habe mit dem Kunde heute gesprochen und muss korrigieren: Der Server hat nicht Dualcore, sondern Quadcore (er meinte vorher “hat 4 Kerne”, aber da ich mir nicht sicher war, ob er mit oder ohne Hyperthreading meint und das auch vergessen hatte zu fragen, dachte ich mir, ich gehe nochmal sicher und schrieb hier “Dualcore” anstatt “Quad” 64bit). Es sind also nicht 2/4 Prozessoren, sondern 4/8 :).
Ach ja und die SSD sei eher “Standard”, deshalb am besten die Concurrency nicht so hoch setzen.

Sollten nun weitere Anpassungen vorgenommen werden? Wenn, ja welche? Bzw. welche vorher von Ihnen genannten Werte dürften jetzt höher/niedriger gesetzt werden (wegen dem Quadcore)?