maintenance_work_mem? shared_buffers? Wieviel Speicher?

Hallo,

Nutzer, die mir in den anderen Threads schon geholfen haben, kennen meine Situation schon. Ich habe einen Zentralen PSQL-Server, auf den andere Anwendungen auf anderen Servern die Inhalte ihrer Datenbanken abspeichern. Mittlerweile sind es schon 3 Datenbanken, die der PSQL-Server verwalten muss. Jetzt gib ich gerade dabei, die postgresql.conf noch ein bisschen zu “tunen”.
Meine Fragen für den Anfang sind erstmal:

Wieviel Speicher sollte ich für die maintenance_work_mem Option freigeben bei 3 Datenbanken?

Wieviel Speicher sollte ich für die shared_buffers Option festlegen?

Welche Optionen könnte man noch genauer konfigurieren, um die Performance zu verbessern?

Zur Info: Alle 3 Datenbanken haben bis jetzt eine Größe von ungf. 700MB.

Gruß
Karl der Heinz!

Ohne zu wissen, wieviel RAM die Kiste hat, ob sie nur für PG dient oder auch noch andere Dinge zu tun hat, wie die workload so ausschaut etc. ist es recht schwer, da konkrete Werte zu nennen.
Shared_buffers setzt man üblicherweise auf ca. 25% RAM, falls es ein dedizierter Server ist. Was noch wichtig ist: work_mem. Aber auch hier können wir so pauschal nix sagen.
Ist das mehr lese-lastig, gibt es viele Inserts/Updates/Deletes?
Sinnvoll ist, zu definieren, ab man man eine Abfrage als ‘zu lange’ betrachtet, und solche Abfragen loggen (log_min_duration oder so ähnlich), und das dann mit EXPLAIN (ANALYSE) untersuchen.

Welche Version ist am Start?

Ach ja: 700MB ist eher wenig…


Andreas

Ich nutze die PostgreSQL Version 9.1.3. Der Server besitzt 2 CPUs und 4 GB RAM. Die Datenbanken bestehen zu 100% aus Text^^. Also sie sind sehr lese-lastig. Ob viele INSERTS und so geschehen, weiß ich nicht. Das machen ja die Anwendungen selber. Aber aufgrundessen, dass sehr oft neue Texte hinzukommen, editiert werden usw. kommen denk ich mal sehr viele Inserts und Updates vor. DELETE eher weniger. Aber bei insgesamt 700MB Datenbanken 1GB shared_buffers? Erscheint mir etwas viel, aber die Datenbanken wachsen ja noch. maintenance_work_mem habe ich erstmal auf 8MB gesetzt. Bei work_men bin ich mir nicht sicher. Brauchst du noch informationen, um dies einschätzen zu können?

work_mem braucht man, um z.B. JOINS zu bilden oder Sortieroperationen durchzuführen. Ich kenne Deine Anfragen nicht. Maintenance_work_mem ist wichtig für Indexpflege und Vacuum.


Andreas

Also die meisten Anfragen sind lesend. Die Anwendung selber führt oft Operationen wie CREATE TABLE und ALTER TABLE aus. Aber lesend überwiegt.

Oft Schemaänderungen durch die Anwendung? Das scheint ein Designfehler zu sein …

Andreas

Gut, “oft CREATE…” ist viell. etwas übertrieben, aber es kommt schon vor. Euer Forum hier nutzt doch bestimmt auch eine PostgreSQL Datenbank oder? Wie habt ihr es denn da konfiguriert?

Nein.


Andreas

Okay, du hast ja, wie es auch auf der offiziellen PostgreSQL Seite steht, gesagt, dass shared_buffers 25% vom Arbeitsspeicher betragen soll. Bei 4GB macht das ja 1024MB. Jetzt will aber der Postgre Server nicht mehr starten. Das hat doch jetzt was mit SHMMAX zu tun oder? Was und wo muss ich da jetzt richtig einstellen, damit ich 1024MB verwenden kann?

Fehlermeldung? Linux? Let me google that for you ?


Andreas

vielen Dank Mr. Google :astonished:

Ich habe jetzt die shmmax auf 2GB gesetzt. 1GB geht jetzt für shared_buffers drauf. Jetzt bleibt also noch 1GB für den Rest. Wie würdet ihr das am besten aufteilen, wenn größtenteils lese-Anforderungen gestellt werden? Durch ein bisschen Suchen im Forum bin ich auf den Befehl “Explain-Analyze” gestoßen. Aber wenn ich den korrekt eingebe, kommt nur eine Tabelle mit 2 Zeilen, wo irgendwelches Zeugs drin steht was ich nicht verstehe. Eingegeben habe ich:

EXPLAIN ANALYZE SELECT * FROM “tabelelenname”;

Du meinst die anderen Speicherparameter wie work_mem, oder was?

Durch ein bisschen Suchen im Forum bin ich auf den Befehl “Explain-Analyze” gestoßen. Aber wenn ich den korrekt eingebe, kommt nur eine Tabelle mit 2 Zeilen, wo irgendwelches Zeugs drin steht was ich nicht verstehe. Eingegeben habe ich:

EXPLAIN ANALYZE SELECT * FROM “tabelelenname”;

Dieser Befehl (ohne analyse) liefert Dir den Ausführungsplan, wie PG die Abfrage ausführen WÜRDE. Da steht dann z.B. drin, wieviel Ergebniszeilen er ERWARTET. Macht man es mit ANALSE, dann wird die Abfrage auch direkt ausgeführt, und man kann sehen, wieviel REAL z.B. an Ergebniszeilen kommt. Man kann dann diese Werte vergleichen, z.B. sollten geschätzte zu realen Ergebnissmenge nicht mehr als 1 Zehnerordnung auseinander liegen. Mit explain (ANALYSE, BUFFERS) kann man auch sehen, wieviel Pages im Cache (shared buffers) lagen und wieviel er von Platte raspeln mußte. Bei Sortieroperationen kann man sehen, ob er im RAM oder extern auf Platte sortiert hat - Du darfst jetzt 3 mal raten, was schneller ist und ob das mit work_mem zusammenhängt.

Und wenn Du jetzt etwas neugierig auf EXPLAIN geowrden bist : Google hab ich Dir ja schon gezeigt, nun suchen nach “explaining explain”!


Andreas

genau! work_mem und maintenance_work_mem
[h=1][/h]

Fein, dann war ja meine Antwort genau passend!

Andreas

okay, vielen Dank!
Ich habe die Werte entsprechend eingestellt. Teilweise auch mit Richtwerten aus dem Internet!
Jetzt bin ich noch auf die Einstellungen: cpu_tuble_cost, cpu_index_tuble_cost und cpu_operator_cost gestoßen. Was die alle bedeuten weiß ich schon. Wirken sich diese Einstellungen erheblich auf die Performance aus? Kann manherausfinden, was man da am idealsten einstellt? Oder sind die default-Einstellungen in Ordnung?

diese Werte läßt Du so!

Andreas

Okay, nachmals vielen Dank :slight_smile: Bei maintenance_work_mem wurde in vielen Foren vorgeschlagen das so einzustellen: “Gesamter RAM des Systems/8” Das erscheint mir etwas viel^^. Aber auf dem Server läuft ja nur Postgre. Von daher geht das denk ich mal. Was meinst du? Passt die Formel so?

Um mit David Fetter zu sprechen: TIAS.
( Try It And See )


Andreas

Okay, :smiley: Genauso mit work_mem: Gesamter RAM/max_connections. Da es bei mir nicht viele sind, ist das alles ziemlich hoch. Aber naja, ich werds prüfen, wenn er richtig produktiv geht. Hier ist der Link mit den Formeln:

HOWTO : Performance tuning for PostgreSQL on Ubuntu/Debian « Samiux’s Blog