[PostNAS Suite] Antw: Re: PostgreSQL-Tuning

So Jun 5 23:40:32 PDT 2016

Hallo zusammen,

wir hatten die angegebenen Parameter bereits, angepasst an unser
System, konfiguriert. Haben deshalb keine Vergleichswerte zur
Standard-PG-Konfiguration.

Unabhängig davon haben wir die Erfahrung gemacht, dass allgemein die
Plattengeschwindigkeit viel bringt.
Platte vom gleichen Hersteller mit 10.000 U/min auf 15.000 U/min hat
bei uns Perfomancesteigerung von ca. 30% gebracht.

Desweiteren hat die Postgres-Version auch einen Einfluss. Von 8.3 auf
9.2 ca. 30% und von 9.2 auf 9.3 ca. nochmal 5%.

Alles grob geschätzte Werte.

Grüße,
Anja Grünberger

>>> "Suhr, Ralf" <Ralf.Suhr at itc-halle.de> 03.06.2016 10:00 >>>
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
_______________________________________________
NAS mailing list
NAS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/nas
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20160606/54ef0696/attachment.html>