[closed] Umbau meines Servers osm.wno-edv-service.de

Hi,

ü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

Danke für die Wünsche - natürlich mit dem Wunsch auf eine möglichst reibungsfreie Umstellung zurück, damit auch du ein paar ruhige Momente hast.

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.

Gruss
walter

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?

Ich hoffe, du meinst nicht die Pakete, die von Ubuntu kommen? Die nehme ich nicht mehr.

Postgis ist hier nicht erwähnt aber auch dabei.

Gruss
walter

aus https://wiki.postgresql.org/wiki/Apt

Ah danke, das sind (teilweise etwas ältere) Backports aus Jessie. Spart man sich etwas Arbeit :smiley:

Hi,

hier mal ein Zwischenstand:

  • Raid-5 repariert
  • Updates von 14.04 LTS nachgezogen - ja, ich bleib bei Trusty.
  • Postgresq 9.4, PostGis 2.1.4 und Qgis 2.6 installiert
  • Datenbank “planet2” mit allen alten Tabellen bis auf planet_osm_* geladen
  • Import vom planet-2014-12-22.osm.bz2 angestoßen

jetzt müsste erst mal für einige Zeit (2-3 Tage!) nix zu tun sein - hoffe ich zumindest.

Gruss
walter

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.

Reine Nervensache Glückssache.

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.

Gruss
walter

https://de.wikipedia.org/wiki/RAID#Die_gebr.C3.A4uchlichen_RAID-Level_im_Einzelnen

Starl OT: Disk-Mirroring der besonderen Art: http://www.heise.de/autos/artikel/Die-skurrilsten-Eigenreparaturen-1717729.html?bild=2;view=bildergalerie

Gruss
walter

ps: Derzeit werden die Relationen importiert, 273000 sind schon drin. Bei 8-9 Rels pro Sekunde wird das wohl noch ein wenig dauern.

Wahnsinn. :sunglasses:

Soviel zum Thema “Relationen belasten die Server nicht”.

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.

Hallo Walter,

wäre ein RaidZ oder RaidZ2 nicht noch besser gewesen?

http://www.open-zfs.org/wiki/Main_Page
https://www.youtube.com/watch?v=xe4_95PJZlw
ZFS bringt im Problemfall einige erleichterungen und es hält auch die Daten sicher. das hat eigendlich alles was man sich wünscht.

Gruß
Michael

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.

Verschneite Grüße aus dem Taunus
walter

Moin,

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.

Knatschige Grüsse
walter

133 GB

Ziemlich frisch aufgesetzte Maschine also noch wenig index bloat.

Simon

Danke, das beruhigt mich etwas.

Gruss
walter

@simon:

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.

Danke und Gruss
walter