Ich setze immer fsync und synchronous_commit auf off, das bedeutet zwar, dass man im Zweifel bei einem Absturz neu importieren muss, aber es bringt (immer je nach Anwendungsfall natürlich) einen Performancegewinn im oberen einstelligen Prozentbereich. Was Du früher schriebst mit räumlichen Indizes beim “pending relations” ist mir nicht klar - weder beim Import noch beim Update sollten räumliche Indizes jemals eine Rolle spielen, die werden nur für Leseabfragen beim Rendern oder sonstigen Analysen gebraucht.
Paul Norman hat gute Ergebnisse mit komprimiertem zfs erzielt: http://www.paulnorman.ca/blog/2014/11/zfs-settings-for-osm2pgsql/ (lange Rede kurzer Sinn: Datenbank auf komprimiertem zfs ist schneller und braucht weniger Platz auf der Disk, d.h. in einer “SSD ist knapp”-Situation kann man zusätzlich zum Performancegewinn auch noch einen größeren Teil der Daten auf die SSD packen). Das hat aber glaub ich mit raidz nichts zu tun.
Danke, werde ich gleich umstellen. (*) Aber nur für den Update, danach hätte ich die gerne wieder an.
Ist schon ok; “pending relations” werden bei den DIFFS verwendet, aber soweit bin ich noch nicht.
nee, groß umstellen will ich jetzt nicht mehr. der Import an sich ist ja schon durch, ich brauche halt “nur noch” zwei weitere Spalten, die ich 1x initialsieren muß. später übernehmen das dann 2 Trigger.
Hab jetzt noch die checkpoint_segmente von 32 auf 128 hochgeschraubt. zudem liegen die auf ssd.
Danke und Gruss
walter
*) Man soll es nicht für möglich halten: Da hab ich ein System mit Raid5 und unterbrechungsfreier Stromversorgung und vorhin reißt mein Kater den Stromstecker aus dem Rechner. Ich könnt ihn grillen.
hi Simon, du hast ja 2x 480 GB SSD für die DB. Fährst du die als einzelne Disks oder bilden die einen Mirror? Rein rechnerisch passt die DB ja knapp auf eine 480-er, nur wäre mir die Reserve echt knapp. Dazu kommt noch das Flat-Nodes-File mit derzeit 25 GB, das sich auf SSD erst richtig wohlfühlt.
Gruss
walter
ps: Derzeit wird - mal wieder - planet_osm_ways_nodes erzeugt und ist etwa zu 60% fertig. Danach “nur noch” der Update von planet_osm_polygon und das Einspielen der aufgelaufenen Diffs.
2 einzelne Disks aus genau den Gründen die du erwähnst (sprich jetzt hat es für eine weile Platz und auch ein reindex etc ist möglich ohne Zeugs rumzuschieben).
Simon
PS: bin aber im Augenblick mit der Performance noch nicht zufrieden, irgendwo hab ich vermutlich ein Bock in der Konfiguration.
Na, dann werde ich mal ~200€ für eine 512-er “zusammenkratzen” müssen. Zusätzlich zu der 256-er und 120-er, die ich schon hab. Nur ohne Mirror fühl ich mich eigentlich nicht so wohl. (*)
Ich würde mir Autovacuum mal näher ansehen. 1 Worker ist etwas wenig. ich werde nach dem Import wieder auf 3 AW gehen. Dazu hab ich noch die AV-Parameter der Tabellen angepasst:
Sind so getuned, dass die häufig geänderten öfter drankommen als die weniger dynamischen - hoffe ich zumindest
Gruss
walter
*) Kann man SSD eigentlich auf Festplatte spiegeln? Ich glaube, da geht die Performance wohl flöten - es sei denn, das OS nimmt zum Lesen immer die schnellere. ?
Ok, beim Lesen macht mdadm das anscheinend genauso wie ich es gerne hätte, aber beim Schreiben würde es wohl eng werden.
Hab ja nur mal ein wenig rumgesponnen.
Stimmt, mir geht es hier aber einzig um die Verfügbarkeit. Backups für OSM als Live-DB machen wirklich keinen Sinn.
Eventuell “spiegel” ich die DB mal mit Postgresql-Mitteln (Synchronisation) und lege den “Spiegel” auf meine Festplatten. Aber erst wenn alles wieder funzt.
Meine Versuche mit Slony waren nicht fruchtbar, da die Synchronisation der Planet-Tabellen ewig dauerte und zudem klemmte. Für normale Tabellen ist Slony aber sehr gut zu gebrauchen, nur Planet-Tabellen sind wohl wirklich zu groß dafür.
Die DB ist geladen und aktiv, allerdings ist der Lag verd… ziemlich groß. Ich werde jetzt nach und nach die Anwendungen reaktivieren und neue Analysen fahren.
Aktiv ist derzeit Boundaries, allerdings noch mit Daten vom 4. januar. Den Lag kann man in der unteren Statuszeile erkennen. 258 Stunden ist schon etwas heftig
Aber zumindest kann man Grenzen herunterladen, die sich ja eh nicht so oft ändern. Die Gebietsänderungen bei uns sind natürlich noch nicht drin.
also werden jeweils alle Daten von 4 Stunden als Diff heruntergeladen und verarbeitet. Dafür braucht der Server ca 1-2 Stunden, je nachdem ob gerade die Nacht dran ist oder der Tag. Tagsüber fallen natürlich mehr Changesets an. Jedesmal, wenn ein Diff-Block von 4h fertig ist, geht die Kurve “einen Zacken” runter.
Erstellt wird die Grafik mit Munin und sie wird alle 5 Minuten aktualisiert.