shared_buffers vs max_locks_per_transaction

Ausgangslage: postgres 8.3 und eine Datenbank mit vielen Tabellen (>10000)

Wir wollten shared_buffers erhöhen (von 768MB auf 1024MB oder besser noch mehr), um mehr daten direkt im RAM halten zu können. Dies ist jedoch nur möglich, wenn max_locks_per_transaction verkleinert wird. Dann funktionieren aber Abfragen, die viele Tabellen betreffen nicht mehr.

Weiss jemand vielleicht mehr über das Zusammenspiel dieser zwei Parameter? Oder hängen diese sie noch mit anderen Einstellungen zusammen?

PS: max_connections ist auf 100 und RAM ist mehr als genug vorhanden

Ein Blick in die Doku:

PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Lock ManagementPostgreSQL: Documentation: Manuals: PostgreSQL 8.4: Managing Kernel Resources

zeigt, daß man an den Kernel-Parametern des OS schrauben kann/sollte.


Andreas

Kannst Du mir das erklären?
Ich bin kein PG-Experte aber soweit wie ich die Doku verstehe, gibt es diesen Zusammenhang nicht…

Vermutlich gehen die Kernel-Ressourcen aus. Ich hab auch 'ne Weile gesucht, und das scheint mir die plausibelste Erklärung zu sein.
Guggst Du andere Antwort von mir.

Andreas

Danke für die Antwort, leider läuft die DB auf einem Windows Server 2003 R2.

Der Fehler von der DB:

out of shared memory
Severity: ERROR
Code: 53200
Hint: You might need to increase max_locks_per_transaction.

Andere Lösungen gibt es wohl nicht?

Klar. Alles, wo der Familienname mit U anfängt und mit nix aufhört wäre eine Lösung …

Ansonsten frag halt mal in einem M$-Forum oder so, wie man da die Kernelparameter tunt.

Andreas

Hilft das Erhöhen von max_locks_per_transaction denn nicht?

Doch hilft, aber dann muss ich shared_buffers kleiner machen, damit die DB überhaupt noch startet.

Auf die 9.0 warten, die kann nativ 64 Bit Windows.

Bisher ist das ein 32 Bit Prozess - was in der Regel nicht schlimm ist, da jede Verbindung erneut 4 GB Ram ansprechen kann. Bei eurem Setup spielt das aber schon eine Rolle.

Hey Jungs,
Ich habe gerade beigetreten und Ich mag das Konzept.
hört sich gut an mir !!!