710 Datenbankeinstellungen und Tuning (postgresql conf) » Historie » Revision 67
« Zurück |
Revision 67/85
(diff)
| Weiter »
[E] Frank S, 11.04.2019 18:22
postgresql.conf: Datenbankeinstellungen und Tuning¶
postgresql.conf
(PostgreSQL Netzwerkkonfiguration (pg_hba.conf))
Datei-Pfad: ..\PostgreSQL\9.6\data\pg96\postgresql.conf
Prüfen der wichtigsten Postgreseinstellungen mittels Datenbankfunktion¶
Die Funktionen heißen TSystem.database_settings__initialize()
und TSystem.database_settings__validate()
und muss bei Neuerungen entsprechend angepasst oder erweitert werden.
Konfiguration PostgreSQL (Beachte Betriebssystem) ab Version 9.3¶
Beachte Programm-Start-Prüfung PRODAT: #9933
Für ein 16GB RAM Systemshared_buffers = 4096MB
Daumenregel: ca 1/4 Des RAMs den Rest für effective_cache_sizetemp_buffers = 8MB
° work_mem = 32MB
(nicht zu hoch, da je sort bzw. hash Operation, auch mehrfach bei komplexen queries)maintenance_work_mem = 512MB
(für VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY, außerdem für restore dumps)dynamic_shared_memory_type = windows
max_worker_processes = 8
> Default ist 8 (keine Änderung nötig). Je nach Unternehmensgröße mehr
° max_parallel_workers_per_gather = 4
fsync = off
synchronous_commit = off
wal_compression = on
wal_buffers = -1
(bis 9.3 8MB)max_wal_size = 3GB
(ab 9.6 Ersatz für checkpoint_segments3 * checkpoint_segments) * 16MB )
° max_locks_per_transaction = 128
effective_cache_size = 12288MB
(Beachte, wenn Server nur für PRODAT dann 3/4 des Arbeitsspeichers, wenn auch andere Programme dort laufen dann 1/2 Arbeitsspeicher. Gibt an wieviel RAM-Cache Postgressql erwarten kann, für Indizies usw)
default_statistics_target = 1000
° seq_page_cost = 2.0
(Mache sequentielle Scans "teurer": Der Planer ist eher geneigt, den Index zu nutzen)
° cursor_tuple_fraction = 0.75
(siehe #6436) (Steuert, dass das CURSOR-FETCH (F2-Fenster) anders errechnet wird und es Blöcke früher zurückgibt)
log_destination = 'eventlog'
(unter Windows)#log_checkpoints = off # default off
(auf Default setzen)log_line_prefix = '<%u
@%d-%t> '
° log_autovacuum_min_duration = 250ms # default -1
(auf Default setzen) > alles was länger 250ms dauert loggen und bei Gelegnheit prüfen
search_path = '"$user",public,TSystem,prodat_languages,Z_99_Deprecated'
datestyle = 'iso, dmy'
standard_conforming_strings = off
(siehe #4860)
° lc_messages = 'en_US.UTF-8'
(Das muß sein, da wir die Fehlermeldungen teilweise parsen und somit auf die Fehler-Strings gehen.)
lc_monetary = 'German_Germany.1252'
(Lokale je nach Land)lc_numeric = 'German_Germany.1252'
lc_time = 'German_Germany.1252'
!!! ° = Für einige Werte gibt es Vorgaben und Prüfungen, in den Client-Sessions.
!!! siehe TSystem.database_settings__initialize
und TSystem.database_settings__validate
(PSQL\0050 System\010 Functions TSystem.sql)
Reload¶
Konfiguration im laufenden Betrieb neu laden...\PostgreSQL\pg96\bin\pg_ctl reload -D ..\PostgreSQL\data\pg96
Linux¶
Könnte durchaus noch weiter getrieben werden, indem man Sie auf die Prodat-DB abstimmt:- http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
- http://www.postgresql.org/docs/current/static/performance-tips.html
- five_steps_perform_2009.pdf Dokument über Einstellungen etc
Hinweis: Fehler im PgAdmin/Server-Status: ungültige Byte-Sequenz für Kodierung "UTF8" ... durch SELECT pg_file_read('pg_log/... kann ignoriert werden, da wir ja ins eventlog schreiben.
Die Anzeige vom Log hier einfach schließen. Liegt an LC_MESSAGES und mehrsprachigen Systemen, vermutlich ein Bug, Workaround LC_MESSAGES='C' (evtl. nicht mit Prodat kompatibel)
Virtualisierung¶
Von [E] Frank S vor mehr als 5 Jahren aktualisiert · 67 Revisionen