über die Feiertage steht der lange überfällige Umbau meines Servers an.
Folgende Probleme will ich damit erschlagen:
Ubuntu 14.04 wird auf 14.10 hochgezogen.
Das Raid-5 läuft in “Degraded Mode”, d.h. eine der Raidplatten ist offline und daher ist der Overhead des Raids zu groß.
Postgresql muß von 9.1 auf die frisch freigegebene Version 9.4 hochgezogen werden.
In dem Rutsch wird auch PostGis auf den aktuellen Stand gebracht (2.0 → 2.1.5) und zudem Topology und Raster installiert.
Es gibt ziemlich viele Probleme in der OSM-Datenbank, da macher Diff doch “verschütt ging”. Daher wird die DB neu aufgesetzt.
Mancher Ballast wird entfernt, der für “gestorbene” Auswertungen nicht mehr benötigt wird.
Noch ist die alte DB aktiv, der Lag beträgt inzwischen aber schon 2 Tage sodaß man von zeitnahen Auswertungen wirklich nicht mehr sprechen kann.
Die Umstellung wird mehrere Tage dauern. Genauer Abschalt-Termin ist noch nicht festgelegt, da manche Vorbereitungen noch nicht fertig sind, aber spätestens morgen geht es wohl in die harte Phase.
ein frohes und ruhiges Weihnachtsfest wünscht euch
walter
OT, aber bist du sicher das du das willst? Der Support für nicht LTS Versionen hört wirklich schlagartig auf mit dem Erscheinen eines neuen Releases. Sprich im April wenn 15.04 rauskommt gibt es keine Updates mehr für 14.10.
Simon, der dran ist ein 13.10er System genau aus obigen Grund loszuwerden.
Ok, ich denk mal drüber nach. Bisher bin ich mit den Zwischenreleases ganz gut gefahren, kann aber dennoch wohl bei 14.04 LTS bleiben. Schießlich hab ich noch den Server2, an dem ich rumspielen Erfahrungen mit den neuesten Releases bekommen kann.
Was ich auf jeden Fall machen muß: 14.04 LTS auf den aktuellen Stand hochziehen. Ging bisher nicht, da die Ubuntu-Leute dabei immer auch Postgresql updaten wollten, und das konnte ich wirklich nicht gebrauchen. Demnächst hole ich mir die Postgresql-Pakete direkt vom Repository der PostgreSQL Global Development Group und werde dadurch unabhängiger von der aktuellen Ubuntu-Release.
Da ich auf einem Produktivserver noch mit Squeeze unterwegs bin (wird bald geändert), musste ich PostGIS immer selbst backporten. Werden die Pakete für Ubuntu auch für LTS-Versionen gepflegt?
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.