Tabellen in den RAM legen

Hallo,

ich habe heute mal wieder

PostgreSQL optimieren
CLT 2010 – 13.-14.03.2010
Andreas ’ads’ Scherbaum
Web: > http://andreas.scherbaum.la/
E-Mail: andreas[at]scherbaum.biz
PGP: 9F67 73D3 43AA B30E CA8F 56E5 3002 8D24 4813 B5FE
13.-14.03.2010

durchgelesen. Dabei fand ich folgenden Stichpunkt:

Soviel RAM wie notwendig: die wichtigen Tabellen/Daten
sollen komplett im RAM liegen

genug RAM haben wir schonmal (4GB) - nur leider weiß ich nicht wie ich die Tabellen da rein bekomme. Habe hier schonmal im Forum gesucht aber leider kann ich nicht nach dem Wort “RAM” suchen (es ist scheinbar zu kurz).
Ich nutze PostgreSQL Version 8.2 unter windows xp.

MfG T

Hatte hier schonmal ein ähnliches Problem: http://www.pg-forum.de/allgemeines/2895-memory-tables.html

Du kannst eine RAM-Disk anlegen und einen Tablespace drauf tun. Das ist aber nicht das, was ads meint. Er meint vielmehr, daß im RAM wichtige Systemtabellen und Indexe gecached werden können. Speicher ist halt durch nichts zu ersetzen, außer durch mehr Speicher.

Andreas

Danke für das Zitieren meines Vortrags :wink:

Also, gemeint ist damit: optimal ist es, wenn du soviel Hauptspeicher hast, dass deine Datenbank da hinein passt.
Das skaliert allerdings auch nur begrenzt, für kleine Datenbanken (sagen wir unter ungefähr 1 GB Größe) ist das jedoch in Ordnung.

Der wichtige Parameter dafür ist “shared_buffers”.

Ich danke auch für die Antworten :wink:

Das hatte ich auch bei meiner Suche gefunden, nur war ich damit nicht so recht zufrieden, weil ‘ads’ in seiner altuellen Doku geschrieben hatte:

Soviel RAM wie notwendig: die wichtigen Tabellen/Daten sollen komplett im RAM liegen

…und wenn das ‘ads’ schon sagt, dann MUSS es ja wohl gehen!

… weiter im Text:

Könntet ihr vorschlagen, welche Konfiguration für 4GB (relativ) optimal ist?
Sollte man lieber ein RAM-Disk (mit wieviel MB/GB?) anlegen und Tablespaces nutzen,
oder shared_buffers so hoch schrauben wie es geht?

Heißt das soviel wie
“Solange deine DBs nicht größer als 1GB werden, erhöhe den Wert für ‘shared_buffers’.
Wenn sie jedoch größer werden, solltest du eine RAM-Disk anlegen und Tablespaces nutzen.” ?

Dann würde ich mich noch für Beziehungen von ‘shared_buffers’ interessieren.
Gibts es die?
Ich denke da Beispielsweise an soetwas:

‘temp_buffers’ = ‘shared_buffers’ / 32
‘work_mem’ = ‘shared_buffers’ /30

Gibt es noch weitere Einstellungen, die Standartmäßig Deaktiviert sind bzw. einen (viel) zu kleinen Standartwert haben, um mehr performace zu bekommen?
Ich denke da zum Beispiel an die ganzen
‘cpu_tuple_cost’, ‘cpu_…’, ‘effective_cache_size’, ‘geqo’
-Werte?

MfG

Habe ich irgendwo etwas von Ramdisk geschrieben?

Um dieses Problem gleich mal zu erschlagen: was passiert, wenn dein Rechner abstürzt? Was ist dann mit den Daten in der Ramdisk?
Genau, die sind weg! Zusätzlich hat PostgreSQL danach sinnlose Pointer in seinen Systemtabellen, die in eine Ramdisk zeigen, die es nicht mehr gibt.

Also vergiss das Thema “Ramdisk” bitte wieder.

So, und jetzt mal zur spannenden Frage: wie groß ist deine Datenbank?

20100111.backup 6.587 KB
20100310.backup 26.382 KB
20100415.backup 80.516 KB

Das soll zeigen wie sie dieses Jahr bis jetzt gewachsen ist.
Im Moment ist sie noch klein, aber sie wächst eben ständig…

Nebenbemerkung: Du solltest dir in deiner Datenbank Gedanken über Partitionierung machen.

Gut, nun zum Problem: deine Datenbank ist größer als dein verfügbarer Hauptspeicher. Demzufolge wird dir auch eine Ramdisk nichts bringen, um alle Daten im Speicher vorzuhalten. Das nur mal als Anmerkung.

Wenn du 4 GB Speicher hast, starte mal mit 1 GB Shared Memory und beobachte die Auslastung der Datenbank. Außerdem soltest du die Free Space Map anpassen (oder gleich mal auf 8.4 wechseln). Ein VACUUM VERBOSE Aufruf ohne weitere Parameter sagt dir am Ende, ob deine FSM-Einstellungen passen.

effective_cache_size kannst du auf ungefähr 2 GB setzen, das dürfte hinkommen, wenn auf der Maschine nichts weiter läuft.
maintenance_work_mem kannst du hochsetzen. Denke mal so 128 MB dürften ein guter Wert sein.

work_mem und temp_buffers hängen nicht von deinem Hauptspeicher sondern vom Workload ab. Dazu kann man also keine pauschalen Aussagen treffen.

Die cost fässt du bitte nicht an, bevor du nicht weisst, was du da tust :wink:

temp_buffers ist der Speicher, der nur für temporäre Tabellen genutzt wird? wenn ich keine habe, kann ich es deaktiviert lassen, ja?

work_mem … hm keine ahnung so richtig… vielleicht der Speicher für die Erstellungen von Abfragen-Ausgaben (also Datenanzeige und so?) ??? kann ich den gleich setzen mit maintenance_work_mem, also 128MB?

und was ist nun mit den 'geqo’s ? “genetec query optimization” hört sich doch nicht schlecht an, oder?? sollte ich das aktivieren und auf ‘on’ setzen? der nachteil wäre dann wieder dass ich dann wieder 6 geqo_Einstellungen habe, bei denen ich nicht weiß, was ich einstellen soll oder was die direkt bewirken …

MfG!

Jein. PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Resource Consumption

work_mem … hm keine ahnung so richtig… vielleicht der Speicher für die Erstellungen von Abfragen-Ausgaben (also Datenanzeige und so?) ??? kann ich den gleich setzen mit maintenance_work_mem, also 128MB?

wichtig z.B. für ORDER BY - Operationen. EXPLAIN ANALYSE von 8.4 zeigt deren Nutzung an. 8.3 bin ich mir grad nicht sicher.

und was ist nun mit den 'geqo’s ? “genetec query optimization” hört sich doch nicht schlecht an, oder?? sollte ich das aktivieren und auf ‘on’ setzen? der nachteil wäre dann wieder dass ich dann wieder 6 geqo_Einstellungen habe, bei denen ich nicht weiß, was ich einstellen soll oder was die direkt bewirken …

MfG!

Auf default lassen und die Doku dazu lesen.


Andreas

Du, vielleicht fängst du erst mal mit den einfachen Einstellungen an, die ich bisher genannt habe. Oh, und “geqo” lässt du bitte schön auf “on” stehen. Wenn das auf “off” steht, ist etwas faul. Wenn du das auf “off” geändert hast, mach die Änderung rückgängig.

Ich möchte mal hinzufügen, dass du dich mit deinen Tests in einem sehr gehobenen Bereich bewegst, der viel Detailwissen erfordert. Du zeigst aber nicht, dass du dieses Wissen besitzt, statt dessen probierst du herum.

Wenn du mehr Performance für deine große Datenbank in deinem eigentlich doch kleinen RAM haben willst, ist es wahrscheinlich am günstigsten, wenn du einen zweiten RAM-Baustein kaufst und hineinsteckst. Die meisten deiner Tuningversuche und Konfigurationsänderungen sind kontraproduktiv. Das muss ich jetzt einfach mal so sagen, ehe du noch weiter probierst.