# Performanceprobleme mit PostgreSQL Server
**URL:** https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181
**Category:** Konfiguration
**Created:** [30. April 2008 um 09:14 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181 "2008-04-30T09:14:28Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@JSpatz](https://www.pg-forum.de/u/JSpatz)
#### Post date: [30. April 2008 um 09:14 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/1 "2008-04-30T09:14:28Z")
HI zusammen,
bei der Installation eines PostgreSQL Servers haben wir folgende Probleme festgestellt und können uns eigentlich nicht vorstellen, das wir die einzigen sind, die diese Probleme haben, deswegen dieser Post.
Schon wenn wir die Scripte laufen lassen, um die Tabellen anzulegen braucht dieses auf unserem neuen Server wesentlich länger als z.B. auf meinem Entwicklungsnotebook. (genauer Zahlen folgen unten). Intensive Analysen haben ergeben, dass das fsync die Ursache des Problems ist. Wenn man dieses in der Config ausschaltet dann fliegt der Server, aber die Frage ist halt, wie ist das bei euren Servern, was habt ihr unternommen, damit diese auf Leistung kommen ?
Hier nun die technischen Daten:
Server:
2x Intel Xeon 5420 2,5GHz QuadCore,
4 GB RAM
6x SATA-II 750 GB Seagate mit 32 MB Cache, davon 4 im RAID10 und 2x Hot Spare
mit folgenden Controllern haben wir getestet
a) Raid-Controller ICP Vortex 5058BL mit 128 MB Cache
b) Raid-Controller Adaptec Raid 5805 mit 512 MB Cache
c) Raid-Controller 3Ware 3W-9690SA-8I-SGL mit 512 MB Cache und Battery Backup Unit BBU
als Betriebssystem haben wir SLES10SP1 (suse enterprise 10 Sp1)
Die Controllerperformance haben wir mit bonnie++ in der Version 1.02-408 getestet.
Und jetzt die Zahlen, um Dateien anzulegen, die ja ausschlaggebend sind, wenn man die Tabellen anlegt, **wobei es mir natürlich nicht nur um das anlegen der Tabellen geht, nur hier sieht man den Effekt am besten.** [INDENT][INDENT] ohne fsync/mit fsync [/INDENT][/INDENT]Controller a: 3400/130
Controller b,c: 5200/13 ☹
(b und c liefern praktisch identische Ergebnisse)
Um auch mal Zahlen zu zeigen, die die Realität wiederspiegeln, hier noch die Zeiten, um das oben angesprochene Script auszuführen:
**Mit fsync**
Dell-Notebook mit Core 2 Duo Prozessor: ~70 Sekunden
Server mit Controller a: ~60 Sekunden
Server mit Controller b, c: ~650 Sekunden ☹
**Ohne fsync**
Dell-Notebook mit Core 2 Duo Prozessor: ~30 Sekunden
Server mit Controller a: ~1 Sekunden
Server mit Controller b, c: ~0,4 Sekunden
Das setzt sich dann z.B. in der Datenübernahme aus der alten Datenbank fort, bei der der Server mit dem alten Controller ca 1:30 Stunden benötigt und mit den neuen Controllern ca. 2:10 Stunden.
Das sind also nicht nur praxisferne Zahlen sondern sie beeinflussen massiv die Performance der Datenbank.
Jetzt die Frage: was habt ihr bei euren Servern gemacht, wie sind eure Erfahrungen, könnte ihr das bestätigen ?
Insbesondere: kann man den Server ohne fsync laufen lassen ? (Die Doku dazu liest sich ja ziemlich gruselig, bis hin zur zerschossenen Datenbank)
Alle anderen Parameter wie synchronous\_commit, full\_pages\_write, commit\_delay … haben wir durchprobiert, die haben aber allenfalls Änderungen im einstelligen Prozentbereich zur Folge. Nützen hier also gar nichts.
Alle Hinweise oder Kommentare sind willkommen.
Danke sehr.
JSpatz
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [30. April 2008 um 09:24 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/2 "2008-04-30T09:24:00Z")
> [@JSpatz](#):
>
> Jetzt die Frage: was habt ihr bei euren Servern gemacht, wie sind eure Erfahrungen, könnte ihr das bestätigen ?
> Insbesondere: kann man den Server ohne fsync laufen lassen ? (Die Doku dazu liest sich ja ziemlich gruselig, bis hin zur zerschossenen Datenbank)
Ja, kann man. Dazu dient ja der Schalter. Natürlich mit den in der Doku erwähnten Risiken und Nebenwirkungen.
> Alle anderen Parameter wie synchronous\_commit, full\_pages\_write, commit\_delay … haben wir durchprobiert, die haben aber allenfalls Änderungen im einstelligen Prozentbereich zur Folge. Nützen hier also gar nichts.
Eben. In Deiner realen Anwendung wird die Hauptlast ja auch nicht durch das Anlegen von Tabellen kommen, vermute ich mal.
> Alle Hinweise oder Kommentare sind willkommen.
>
> Danke sehr.
> JSpatz
Was etwas bringt ist die Verteilung von Tabellen, Indexen und dem TX-Log auf unterschiedliche Spindeln. Falls die Daten nicht wichtig sind, ist natürlich fsync=off ideal…
Andreas
---
### Author:  [@JSpatz](https://www.pg-forum.de/u/JSpatz)
#### Post date: [30. April 2008 um 09:38 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/3 "2008-04-30T09:38:24Z")
HI,
die Frage war natürlich nicht so gemeint, wozu der Schalter dient, sondern, wie die Erfahrungen sind, wenn man eine Datenbank ohne fsync laufen lässt. Wie groß ist das Risiko bei einem Server mit USV und Batteriegepuffertem Raid-Controller?
> Eben. In Deiner realen Anwendung wird die Hauptlast ja auch nicht durch das Anlegen von Tabellen kommen, vermute ich mal.
Sicher ist das so, aber wie weiter unten beschrieben ist es eben nicht nur das Anlegen der Tabellen, sondern da sieht man es halt am besten.
Ich hätte evtl. stärker auf den Unterschied zwischen Kontroller a und b,c hinweisen sollen. Der erste liefert ja halbwegs Performance, obwohl nominell wesentlich langsamer und 4 Jahre älter.
Danke
---
### Author:  [@ads](https://www.pg-forum.de/u/ads)
#### Post date: [30. April 2008 um 11:16 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/4 "2008-04-30T11:16:45Z")
Aus der Übersicht kann man aber noch nicht wirklich erkennen, wo die Performance verloren geht.
Gibt es für die verschiedenen Daten mal bonnie++ Analysen?
---
### Author:  [@JSpatz](https://www.pg-forum.de/u/JSpatz)
#### Post date: [30. April 2008 um 11:24 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/5 "2008-04-30T11:24:22Z")
Hi zusammen,
wie gewünscht hier eine Datei mit den 3 Analysen.
der erste Rechner ist ein Desktop - Rechner, der zweite der mit Controller a, der der Dritte der mit Controller c.
Übrigens haben wir unterdessen einmal ubuntu-Server installiert und siehe da, es scheint, als ob hier die Werte wesentlich besser sind. Evtlm handelt es sich hier um ein Suse Problem.
Gruss
Jspatz
---
### Author:  [@ads](https://www.pg-forum.de/u/ads)
#### Post date: [30. April 2008 um 11:40 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/6 "2008-04-30T11:40:43Z")
Eventuell liegt es auch an irgendwelchen Einstellungen - sowohl beim System wie in der PostgreSQL Config.
Das Problem ist allerdings aus der Ferne dann schwer einzuschätzen ☹
---
### Author:  [@Gisman](https://www.pg-forum.de/u/Gisman)
#### Post date: [30. April 2008 um 11:51 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/7 "2008-04-30T11:51:51Z")
> [@JSpatz](#):
>
> Übrigens haben wir unterdessen einmal ubuntu-Server installiert und siehe da, es scheint, als ob hier die Werte wesentlich besser sind. Evtlm handelt es sich hier um ein Suse Problem.
>
> Gruss
> Jspatz
Interessant. Hast du PostgresSQL per Suse-rpm installiert oder selbst kompiliert? Mein selbstkompilierter Server hier läuft prima auf openSuse 10.1. Mit den rpms hatte ich immer Probleme, da hat nix richtig zusammenpasst 🙂
Gruß Uwe
---
### Author:  [@JSpatz](https://www.pg-forum.de/u/JSpatz)
#### Post date: [30. April 2008 um 17:57 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/8 "2008-04-30T17:57:19Z")
wir haben das neueste rpm von suse benutzt
---
### Author:  [@Gisman](https://www.pg-forum.de/u/Gisman)
#### Post date: [3. Mai 2008 um 10:37 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/9 "2008-05-03T10:37:03Z")
Vielleicht testest du mal eine kompilierte Version. Der Aufwand sollte vertretbar sein, wenn du nur den Postgres-Server brauchst. Du kannst dir dann auch mit checkinstall ein eigenes rpm mit eigenen Vorgaben bauen, wenn es funktioniert. Bei meiner Installatioin als Geodatenserver war immer das Problem, das mehrere Optionen nicht so gesetzt waren, wie sie andere Tools benötigten, deshalb habe ich auf die rpms verzichtet.
Gruß Uwe
---
### Author:  [@system](https://www.pg-forum.de/u/system)
#### Post date: [21. Februar 2021 um 06:49 UTC](https://www.pg-forum.de/t/performanceprobleme-mit-postgresql-server/3181/10 "2021-02-21T06:49:06Z")