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

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

gis=> \dt+
List of relations
Schema | Name | Type | Owner | Size | Description
--------±-------------------±------±---------±-----------±------------
public | planet_osm_line | table | www-data | 59 GB |
public | planet_osm_nodes | table | www-data | 8192 bytes |
public | planet_osm_point | table | www-data | 12 GB |
public | planet_osm_polygon | table | www-data | 56 GB |
public | planet_osm_rels | table | www-data | 1599 MB |
public | planet_osm_roads | table | www-data | 9987 MB |
public | planet_osm_ways | table | www-data | 61 GB |
public | spatial_ref_sys | table | www-data | 3224 kB |

\di+

Schema | Name | Type | Owner | Table | Size | Description
--------±-------------------------±------±---------±-------------------±-----------±------------
public | addr_inter_idx | index | www-data | planet_osm_line | 101 MB |
public | addr_point_idx | index | www-data | planet_osm_point | 1896 MB |
public | b_addr_idx | index | www-data | planet_osm_polygon | 919 MB |
public | b_no_addr_idx | index | www-data | planet_osm_polygon | 6831 MB |
public | planet_osm_line_index | index | www-data | planet_osm_line | 14 GB |
public | planet_osm_line_pkey | index | www-data | planet_osm_line | 2748 MB |
public | planet_osm_nodes_pkey | index | www-data | planet_osm_nodes | 8192 bytes |
public | planet_osm_point_index | index | www-data | planet_osm_point | 4410 MB |
public | planet_osm_point_pkey | index | www-data | planet_osm_point | 1679 MB |
public | planet_osm_polygon_index | index | www-data | planet_osm_polygon | 17 GB |
public | planet_osm_polygon_pkey | index | www-data | planet_osm_polygon | 3690 MB |
public | planet_osm_rels_parts | index | www-data | planet_osm_rels | 1324 MB |
public | planet_osm_rels_pkey | index | www-data | planet_osm_rels | 68 MB |
public | planet_osm_roads_index | index | www-data | planet_osm_roads | 1559 MB |
public | planet_osm_roads_pkey | index | www-data | planet_osm_roads | 390 MB |
public | planet_osm_ways_nodes | index | www-data | planet_osm_ways | 133 GB |
public | planet_osm_ways_pkey | index | www-data | planet_osm_ways | 5878 MB |
public | residential_idx | index | www-data | planet_osm_polygon | 134 MB |
public | spatial_ref_sys_pkey | index | www-data | spatial_ref_sys | 144 kB |

Ist ne 32GB Kiste mit 2 480GB SSDs für die DB. Conf schicke ich noch, ist aber nichts aussergewöhnliches drin.

Simon

Danke,

56 GB macht mir ja noch Hoffnung.

Gruss
walter

Bitte die Conf auch an mich - ich träume auch gerade von einem eigenen Server :slight_smile: und eure Unterhaltung ist sehr aufschlussreich für mich.

Gruss & Danke,
Stefan aka nordie69

meine aktuelle Config kannst du hier finden: http://osm.wno-edv-service.de:82/index.php/technisches-umfeld/postgresql-config-files

Aber ob die wirklich so ok ist? Wird sich rausstellen.

Gruss
walter

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.

Bye
Frederik

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. :rage: :rage: :rage: Ich könnt ihn grillen.

Ich will sofort wieder in meine Gummizelle!!!

DANKE!

Stefan

Also doch ne Laufkatze :smiley:

@ Simon:

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.