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

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.

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:


planet_osm_line:    autovacuum_enabled=true, autovacuum_vacuum_scale_factor=0.02, autovacuum_analyze_scale_factor=0.01
planet_osm_point:   autovacuum_enabled=true, autovacuum_vacuum_scale_factor=0.0005, autovacuum_analyze_scale_factor=0.001
planet_osm_polygon: autovacuum_enabled=true, autovacuum_vacuum_scale_factor=0.002, autovacuum_analyze_scale_factor=0.001
planet_osm_rels:    autovacuum_enabled=true, autovacuum_vacuum_scale_factor=0.1, autovacuum_analyze_scale_factor=0.1  
planet_osm_roads:   autovacuum_enabled=true, autovacuum_vacuum_scale_factor=0.02, autovacuum_analyze_scale_factor=0.02
planet_osm_ways:    autovacuum_enabled=true, autovacuum_vacuum_scale_factor=0.002, autovacuum_analyze_scale_factor=0.001  
planet_osm_nodes:   autovacuum=off

Sind so getuned, dass die häufig geänderten öfter drankommen als die weniger dynamischen - hoffe ich zumindest :wink:

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. ?

http://serverfault.com/questions/380850/what-would-happen-if-i-did-a-raid-on-a-ssd-and-an-hdd und weitere Google-Suche sagen, das das vermutlich meist keine gute Idee ist.

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. :wink:

Gruss
walter

Mirroring nützt für die Verfügbarkeit: Dienst läuft weiter, auch wenn eine Disk down ist.
Für die Sicherheit (im Sinn von Backup) bringt es nichts.

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.

Gruss
walter

Gerade gelesen: http://www.postgresql.org/docs/9.4/interactive/continuous-archiving.html , aber das möchte ich mir nicht antun :frowning:

HI, so langsam kommt Leben in die Bude.

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 :frowning:

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.

Gruss
walter

Hier mal der LAG als Grafik:

Derzeit ist in configuration.txt folgendes eingestellt:

baseUrl=http://planet.openstreetmap.org/replication/minute
ChangeFileBeginFormat=yyyyMMddHH
changeFileEndFormat=yyyyMMddHH
maxInterval=14400

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.

Gruss
walter

Hi,

der Lag ist jetzt bei seinem üblichen Wert von einigen Minuten angekommen. Damit ist der Umbau - leider viel zu spät - abgeschlossen.

das werde ich mir dieses Jahr nicht nochmal antun - und euch auch nicht.

Gruss
walter

Hallo Walter,

beim Aufruf der Postcode Boundaries Karte laut deinem Forums-Footer kommt immer noch eine Fehlermeldung wegen Maintenance … Absicht?

nööööööööööööööööö :frowning:

ich schau mal nach - aber heute net mehr. probier es mal ab morgen mittag.

Gruss
walter