[PostNAS Suite] PostgreSQL-Tuning

Fr Jun 3 01:00:10 PDT 2016

Hallo Liste,

wer noch nie an den PostgreSQL Einstellungen Veränderungen vorgenommen hat, kann http://pgtune.leopard.in.ua/ als Startpunkt nehmen, was immer besser als die Voreinstellungen für kleine Systeme ist. Die Hardware ist zu unterschiedlich, um eine gemeinsame Konfiguration zu finden, die für alle passt.

Gr
Ralf

--

Am Donnerstag 02 Juni 2016, 14:15:58 schrieb Schepers, Benjamin:
> Hallo zusammen,
> 
> das sind "meine" Parameter (Hardware: 128GB RAM; Xeon 3,6GHz; SSD):
> 
> # max_connections = 500
> # shared_buffers = 16GB
> # temp_buffers = 1GB
> # work_mem = 1GB
> # maintenance_work_mem = 4GB
> # effective_io_concurrency = 8
> # max_worker_processes = 8
> # wal_buffers = -1
> # checkpoint_segments = 256
> # checkpoint_timeout = 5min
> # checkpoint_completion_target = 0.9
> # seq_page_cost = 1.0
> # random_page_cost = 1.1   <-- laut Marvin wäre das noch auf 1.01 zu setzen
> # effective_cache_size = 64GB
> # autovacuum = on
> 
> 
> 
> =>
> 
> LOG 2015-11-22 20:23:43
> Import-Version: 287fce5
> GDAL-Version: GDAL 1.11.3, released 2015/09/16
> 
> ...
> 
> SQL RUNNING: alkis-signaturen.sql 2015-11-23 00:40:46
> SQL RUNNING: alkis-ableitungsregeln.sql 2015-11-23 00:40:52
> 
>  ALKIS-Modellart | #Objekte
> -----------------+----------
>  DLKM            | 12538852
>  NWABK           | 10343396
>  DKKM1000        |  5950278
>  DKKM500         |  4845664
>  NWDKOM          |  3069303
>  NWDKOMK         |  1162135
>  NWABKK5         |   345080
> (7 Zeilen)
> 
> ...
> 
> END 2015-11-24 10:21:51
> LOG: /data/alkis/alkis_2014/alkis_2014-2015-11-22-20-23.log
> 
> 
> ALSO: ca. 38 Stunden für eine Vollausstattung von 14 Katasterämtern
> 
> 
> 
> Mit freundlichen Grüßen
> Im Auftrag
> 
> Benjamin Schepers
> 
> 
> Luftbild und Geoinformationssysteme
> Kronprinzenstraße 35
> 45128 Essen
> Fon: +49 201 2069-232
> Fax: +49 201 2069-500
> schepers at rvr-online.de
> 
> 
> 
> Die Regionaldirektorin
> Kronprinzenstraße 35
> 45128 Essen
> Zentrale: +49 (0) 201 2069-0
> Fax: +49 (0) 201 2069-500
> www.metropoleruhr.de
> 
> Postfach 10 32 64
> 45032 Essen
> 
> Steuernummer: RVR 112/5797/0116
> USt.-ldNr.: DE 173867500
> 
> Diese E-Mail koennte vertrauliche und/oder rechtlich geschuetzte
> Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
> diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
> Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die
> unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This e-mail may
> contain confidential and/or privileged information. If you are not the
> intended recipient (or have received this e-mail in error) please notify
> the sender immediately and destroy this e-mail. Any unauthorised copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden. -----Ursprüngliche Nachricht-----
> Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Jäger, Frank
> (KRZ) Gesendet: Donnerstag, 2. Juni 2016 12:36
> An: Mailingliste (nas at lists.osgeo.org)
> Betreff: [PostNAS Suite] PostgreSQL-Tuning
> 
> Hallo,
> auf unserem Treffen am 25. Mai in Unna berichte Marvin Brandt von den
> Ergebnissen des Datenbank-Tuning.
> 
> Die zeitkritische nächtliche PostNAS-Konvertierung des kompletten
> Kreisgebietes mit Nachverarbeitung konnte von 6 auf 1,5 Std. verkürzt
> werden. Die Optimierung hat also eine Ersparnis von 75 % gebracht. Dies
> wurde mit relativ einfachen Mitteln erreicht. Einige "default"-Parameter in
> der postgresql.conf wurden ersetzt durch individuell kalkulierte Werte.
> Ziel ist es dabei, den RAM-Speicher der Maschine mit Puffern optimal zu
> nutzen, um so die (langsamen) physischen Plattenzugriffe zu minimieren.
> Anregung dazu gab ein Vortrag auf der FOSSGIS 2013 [1].
> 
> Dies beeindruckende Verhältnis von Aufwand und Wirkung hat mich dazu
> animiert, das auch mal zu versuchen. Erste Ergebnisse zeigen hier aber nur
> einen Effekt von ca. 5 % Zeitersparnis. Dieser Unterschied liegt vermutlich
> in einer anderen Ausgangs-Situation. Unna: physische Maschine mit
> physischer HDD.
> Krz: virtuelle Maschine mit virtuellen Platten in einem SAN [2].
> 
> Dieses "SAN" ist bereits hoch optimiert. Ein Schreibzugriff auf die Platte
> wird gepuffert und ggf. auf SSD statt auf HDD geschrieben (wird im System
> entschieden). Es gibt im Datenbank-Server daher keine so großen
> Geschwindigkeitsunterschiede zwischen (virtuellem) RAM und (virtueller)
> HDD. Somit bringt die Verschiebung zwischen diesen beiden Teilen einen
> kleineren Effekt.
> 
> Hat das noch jemand versucht?
> Wie sind eure Erfahrungen?
> 
> [1] https://www.youtube.com/watch?v=wRnI_r0ZAf0
> [2] https://de.wikipedia.org/wiki/Storage_Area_Network
> 
> Mit freundlichen Grüßen
> Frank Jäger
> 
> Kommunales Rechenzentrum
> Minden-Ravensberg/Lippe
> Tel.: 05261 / 252 - 185
> mailto:f.jaeger at krz.de
> http://www.krz.de/
> 
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas