Experte für Einstellungen in PostgreSQL

Ich hoffe ich werde hier jetzt nicht gesteinigt und meine Anfrage hier ist erlaubt.

Wir nutzen eine Software, welche auch PostgreSQL aufsetzt. Der Hersteller der Software will hier aber keinen Support mehr für die SQL Datenbank liefern und verweist auf einen Experten um die Performance zu verbessern.

Unser IT’ler hat aber leider mit Postgree wenig am Hut. Gibt es hier die Möglichkeit jemanden zu finden, der sich einmal unsere Einstellungen ansieht und ggf. Optimierungen gegen Bezahlung vornimmt?

Viele Grüße

Thomas

Das sieht man schon an der Schreibweise des Namens :wink:

Zur eigentlichen Frage: klar gibt’s Experten dafür (@akretschmer verdient z.B. seine Brötchen damit).

Allerdings geht das nicht einfach durch analysieren der aktuellen Einstellungen. Man muss auch viel über die Abfragen wissen, welche Teile genau das Problem sind usw.

Viele Performanceprobleme lassen sich auch gar nicht durch die Konfiguration ändern, sondern da muss der eigentlich Code (=SQL) optimiert werden.

Das übliche Vorgehen ist, dass man z.B. das loggen von langsamen Abfragen einschaltet, und sich dann eine nach der anderen vornimmt.

Du kannst auch gerne die drängendsten Probleme hier einfach mal zeigen.

1 Like

gut geschrieben von @castorp :wink:

Ja, als 2ndQuadrant haben wir sowas gern und oft gemacht, EDB ist da nicht ganz so interessiert.

Aus der Erfahrung kann ich aber @castorp nur Recht geben: durch Parameteroptimierung kannst Du die Performance im Bereich weniger % verbessern oder verschlechtern, durch schlechtes Tabellendesign, fehlende Indexe etc. Wir haben bei 2ndQ solche Anfrage gern mit einigen Tagen (remote) - Consulting gelöst. Die grobe Richtung ist a) finden problematischer Abfragen, b) analyse dieser via EXPLAIN und c) Optimierung soweit möglich.

Falls ihr evtl. Interesse an einem 24*7 - Supportvertrag habt, könnten wir das da mit unterbringen. Melde Dich bei mir, wenn das für Euch interessant klingt.

andreas dot kretschmer at enterprisedb dot com

Es handelt sich hierbei um ein Kundenverwaltungsprogramm, in dem Kunden und Verträge aufgerufen werden. Insgesamt geht das eigentlich schon zügig, die Sekunde Wartezeit soll aber bei optimaler Konfiguration nicht nötig sein laut Hersteller.

Ansonsten ist die Datenbank seit Jahren eigentlich unproblematisch / unauffällig gelaufen.

Ein “größeres” Problem ist nun ein Task, welcher im Hintergrund ausgeführt wird und unsere Daten mit einem Server des Softwareherstellers abgleicht. Dieser Abgleich soll nach wenigen Sekunden lt. Hersteller beendet sein. Dies hat er mir anhand seines Log nachgewiesen. Der Abgleich wird alle 10 Minuten erneut durchgeführt. Normal haben wir eine System Auslastung des Prozessors von meist unter 10%. Startet nun dieser Task, dann haben wir 50% oder auch mehr. Dabei sehe ich im Taskmanager 3x Postgre mit einer sehr konstanten Prozessorlast. Diese Last geht nicht zurück, wenn der Abgleich nach angeblich wenigen Sekunden beendet ist. Erst wenn nach 10 Minuten der neue Abgleich laufen soll, habe ich einen kurzen Rückgang der Auslastung, danach geht es aber sofort wieder hoch. Deaktiviere ich diesen Abgleich, habe ich keine Probleme.

Aus meiner Sicht hängt sich dieser Abgleich einfach nur auf und produziert eine dauernde Last, bis er eben erneut gestartet wird. Eigentlich ein Problem des Herstellers. Dieser hat aber jetzt pauschal darauf verwiesen, einmal die Konfiguration optimieren zu lassen.

Ein 24*7 Support hört sich natürlich klasse an. Da wir aber nur 5 Arbeitsplätze haben und bisher eigentlich kaum etwas an der DB angefallen ist, wird das wohl etwas überdimensioniert sein. Ich melde mich aber trotzdem gerne mal! Dem Hersteller habe ich erstmal geschrieben, dass ich es nicht in den Einstellungen begründet sehe, da alle anderen DB Abfragen eigentlich problemlos laufen. Mal sehen was da wieder kommt.

Trotzdem könnte grundsätzlich mal über die Konfiguration schauen vielleicht nicht schaden…

man müßte halt wissen, was da passiert. Wenn z.B. Euer Abgleichprozess sehr viele Datensätze ändert, dann mag das in wenigen Sekunden durch sein - aber aufgrund der Änderungen startet dann das Autovacuum, was dann die weitere Last erzeugt. Mal so als Schuß aus der Hüfte, das ist nur eine Vermutung.

Meines Wissens nach werden hier nur Daten zum Server der Softwarefirma geschickt, aber keine geänderten Daten empfangen (außer ggf. Empfangsbestätigung oder so).

Ich habe nun die folgende Rückmeldung erhalten:

das Release 10.5 ist aus dem Jahr 2018. In diesem Fall würden wir empfehlen, die aktuellste Postgres-Version zu installieren, um auszuschließen dass die Performance-Probleme damit zusammenhängen.
Unsere Entwickler haben mir die Info gegeben, dass die zusätzlichen postgres.exe Prozesse, die während des Connector-Laufs starten, normal sind und auf die Datenbank-Threads zurückzuführen sind, die der Connector öffnet um die Event-Tabellen zum Synchronisieren auszulesen. Diese Threads sollten jedoch die CPU nicht derart belasten.

Somit müsste bei uns ein Update installiert werden. Ob es was bringt, möchte ich dann aber doch fast bezweifeln… Für den PG Admin gibt es offenbar auch eine neuere Version habe ich gesehen…

Ansonsten sind auch unter PostgreSQL: Professional Services - Europe weitere Firmen gelistet die Support anbieten.

Für kleine Fragen zwischendurch, sind die Mailing Listen auch ein guter Anlaufpunkt

ja, in der 10er-Reihe ist Version 10.15 aktuell, als Hauptversion 13.1. Da sind etliche Features und Performanceverbesserungen drin. Erfahrungsgemäß läuft PG unter einem Betriebssystem auch besser als auf einem designierten Spiele-OS. PG Admin ist nur ein bunter Client, auf die Performance von Abfragen in der DB hat der keinen Einfluß.

Vielen Dank schon einmal für die Antworten! Das hilft mir in jedem Fall einmal weiter!

Ich habe jetzt einmal angefragt, welche Postgre Version es denn sein soll (neueste 10er oder 13) und würde mich dann mal um Unterstützung bei der Umstellung kümmern.

Nur so am Rande: die Datenbank heißt PostgreSQL, die Kurzform ist Postgres

Vielen Dank, werde ich befolgen. Dann oute ich mich zukünftig vielleicht nicht gleich als völlig planlos!