bei uns wurde eine neue Autobahn gebaut, Fertigstellung zum 1.10.2019. Eine Woche vorher habe ich die A94 von construction auf highway geändert. Auf https://www.openstreetmap.de/karte.html?zoom=11&lat=48.21126&lon=12.11377&layers=B000TT ist auch nach etwa 7 Wochen die Kachelansicht noch auf dem Stand vor der A94. (Höherer Zoomstufen haben es dann schon berechnet.)
Tiles auf den Zoomstufen 13 bis 19 werden per Tile-Expiry neu berechnet, wenn sich etwas geändert hat (ggf. nach dem ersten Zugriff nach der Änderung). Tiles der niederigeren Zoomstufen werden beim Serversetup vorberechnet. Für weitere Fragen musst du dich an Sven Geggus wenden, er hat den Server aufgesetzt.
Das scheint nicht nur so, die beiden Maschinen haben exakt das selbe Setup sodass zum Systemupdate auch mal eine davon temporär raus genommen werden kann.
Es ist tatsächlich so, dass es derzeit keinen Cronjob gibt um die kleinen Zoomlevel neu zu rendern. Das liegt daran, dass es derzeit ziemlich teuer ist das zu tun und man da vermutlich die Indexe der Datenbank noch etwas tunen müsste damit das effizienter funktioniert. Den Aufwand habe ich bislang gescheut und mir gedacht dass sich in diesen Zoomleveln ja ohnehin wenig ändert.
Wenn sich da jemand berufen fühlt ein paar geeignete Indexe bei zu steuern, immer gerne.
Ich habe vor etwa einem halben Jahr ein wenig Index-Tuning für OSM Carto gemacht. Viel kam nicht heraus, aber folgende Indexe könntest du noch ausprobieren (ich fand, dass sie einen Effekt hatten). Beachte bitte, dass diese für eine Datenbank mit klassischem OSM-Carto-Layout gelten, du musst sie noch an dein Hstore-Layout anpassen.
CREATE INDEX planet_osm_point_place
ON planet_osm_point USING GIST (way)
WHERE place IN ('city', 'town') AND name is NOT NULL;
CREATE INDEX planet_osm_roads_low_zoom
ON planet_osm_roads USING GIST (way)
WHERE highway IS NOT NULL
OR (railway IS NOT NULL AND railway != 'preserved'
AND (service IS NULL OR service NOT IN ('spur', 'siding', 'yard')));
CREATE INDEX planet_osm_line_name
ON planet_osm_line USING GIST (way)
WHERE name IS NOT NULL;
CREATE INDEX planet_osm_point_capital_names ON planet_osm_point USING GIST(way) WHERE tags @> 'capital=>yes';
Bei den Indexen planet_osm_hstore_polygon_military und planet_osm_hstore_polygon_water solltest du prüfen, ob da nicht noch ein “AND building IS NULL” fehlt. Die partiellen Indexe nutzt PostgreSQL nur, wenn die WHERE-Bedingung näherungsweise identisch ist.
Der originale OSM-Carto-Stil schlägt noch einen zusätzlichen partiellen Index auf planet_osm_polygon vor, der für die Zoomstufen 7 bis 10 hilfreich ist:
CREATE INDEX planet_osm_polygon_way_area_z10
ON planet_osm_polygon USING GIST (way)
WHERE way_area > 23300;
Der Layer landcover_low_zoom lässt sich meinen Untersuchungen nach nicht mit einem weiteren Index (auf die WHERE-Bedingung + way_area-Filter) beschleunigen. Da müsste man mit vereinfachten Geometrien nachhelfen.
Je mehr Indexe man hat, desto mehr Index-Bloat hat man. Man sollte daher regelmäßig (Cronjob/Systemd-Timer) diese Indexe neu bauen und dann den alten Index per “DROP INDEX” löschen.
Die Indexe für capital und way_area halte ich für besonders empfehlenswert. Den speziellen Index für Fähren hast du schon (das ist ein Performance-Klassiker).
Vermutlich liegt es aber nicht nur am Rendering, sondern evtl. auch an einer niedrigen Priorität für dirty Anfragen, die ggf. auch verworfen werden?
Zum Test habe ich jeweils zwei Anfragen für z18 gestellt, die auf beiden Servern alle um die zwei Stunden benötigten. Noch nie gerenderte Tiles in z18, durch Verschieben der Karte angestoßen, werden dagegen relativ zügig, zumindest im Minutenbereich, neu erstellt.
Gibt es ein öffentliches Munin, wo man die aktuelle Auslastung der Server sehen könnte? Oder legst Du schon neue Indizes an und wir sollten mit dirty Anfragen besser warten?