Wieso setzt Du eigentlich ein RAID-5 ein? Ich habe mir irgendwann überlegt: brauche ich überhaupt Redundanz? Und seit über 5 Jahren habe ich mit einem MDADM-RAID-0 gute Erfahrungen gemacht, nicht ein Aussetzer.
Wenn das RAID kaputt geht, spiele ich halt die Daten neu ein. Wirkt sich effizient vermutlich aber nur beim Schreiben aus, da im RAID-5 ja auch schnell gelesen wird. Müsste ich mal benchmarken, sobald die neuen SSDs eingebaut wurden.
Neu einspielen? Mach ich gerade und hoffe, dass ich in 2-3 Tagen damit durch bin. Aber nicht wegen dem Raid, sondern weil ich Postgresql und die DB komplett neu aufgesetzt habe. Und bis die Daten wieder zeitnah sind, muß ich auch noch die Diffs ab dem 22.12. einspielen, das dauert auch noch ein wenig (1-2 Tage).
Mein Raid-5 hat 3x2TB und gibt mir daher 4 TB “robusten” Diskspace. Damit kann ich ziemlich gut schlafen. Ich hatte in 2 Jahren 2x einen Plattenausfall. 1x war die Platte wirklich defekt und wurde ausgetauscht. Dieses mal war es nur ein “Klemmer”.
In beiden Fällen ein mdadm -manage /dev/md0 -a /dev/sddX und nach ~4 Stunden war der Resync fertig. Wärend der ganzen Zeit der Störungen waren die Daten online, nur die Performance war dann ziemlich schlecht.
ach ja: die Indices liegen auf SSD (120+250GB), sind aber nicht gespiegelt.
Die “Micro-Relationen”, auf die du hier wohl unwissentlich ansprichst, brauchen nur Millisekunden. Die “richtigen” mit tausenden von Membern brauchen etwas länger. Und da wirkt es sich natürlich aus, dass beim Import noch keinerlei Spatiale Indices in der DB vorhanden sind. Dabei muss der Rechner “ein wenig länger” nach den Members suchen - und das geht dann in den derzeit ca 90 Millionen Ways derzeit nur sequentiell. (*)
Gruss
walter
*) Mal sehen, ob ich den Betreuern von osm2pgsql schmackhaft machen kann, bereits beim Import Indices zu erzeugen. Besonders zwischen Import der Ways und Import der Rels - da müsste das echt was bringen.
Der Ansatz von RaidZ ist ganz interessant, nur ist mein Raid “älter” als Sep. 2013, als das Zeug erstmalig auftauchte. Ich hab das Raid ja auch nicht neu aufgesetzt, sondern es nur wieder stabilisiert, ganz so wie es im Problemfall vorgesehen ist.
Zudem haut mich das hier nicht vom Hocker “The main technical goal of OpenZFS is easier sharing of code between platforms”, da ich mit Linux eh schon gut bedient bin. Wenn hier “Our community brings together developers from the illumos, FreeBSD, Linux, and OS X platforms” auch Windows stehen würde, dann wäre das ein Hammer - Obwohl: Windows boote ich nur noch zum Spielen.
Was ich aber für 2015 in der Pipeline habe, ist ein Hardware-Raid in einer extra Box (kein NAS). HR auf dem Motherboard ist nämlich was für die Tonne.
kleine Frage an diejenigen, die einen vollen Planeten im osm2pgsql-Schema fahren: Wie groß ist bei euch der Index planet_osm_ways_nodes?
Abfrage in psql mit \di+ planet_osm_ways_nodes
Bei mir ist der inzwischen 118 GB groß und immer noch nicht fertig. Ich meine, vorher war der größte Index etwa 110 GB gross. Daher möchte ich den Job nicht knapp vor dem Ziel killen.
Ich krieg noch die Krise. Jetzt klemmt er bei einem Update von planet_osm_polygon, der über alle 160 Mio Datensätze gehen muß, da ich unbedingt noch zwei zusätzliche Spalten brauche.
Dazu legt Postgresql ja eine Kopie der alten Datensätze an und die physikalische Größe der Tabelle auf der Platte verdoppelt sich temporär. Und das ist das einzige was ich bei dem Update sehe. Derzeit hab ich da 111 GB von ??? mit einer Zunahme von 1-2 GB/Stunde.
Also wieder die Frage: Wie groß ist planet_osm_polygon bei dir? \d+ planet_osm_polygon oder besser noch ein \d+ der ganzen DB.
Ich habe die Parameter von postgresql.conf analog zu der vorherigen Version gesetzt - meine ich zumindest. Aber irgendwas muß ich übersehen haben. Eventuell schickst du mir per Mail noch postgresql.conf und die Info, wieviel Memory dein Rechner hat. Meine Kiste hat 24 GB und ich habe dafür massig was an die DB gegeben. Ich werde das halt nochmals überprüfen müssen.
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.