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