Mehr

So optimieren Sie das Rendering von Layer-Gruppen in Geoserver

So optimieren Sie das Rendering von Layer-Gruppen in Geoserver


Ich verwende GeoServer 2.8 auf Ubuntu 14 als WAR in Tomcat 7. Ich habe einen 8-Kern-Rechner mit 16 GB RAM und habe eine großzügige Heap-Größe von 4 GB zugelassen. Ich habe JAI installiert und aktiviert. Meta-Tiling ist auf 8x4 eingestellt und ich habe 3 GB für das Rendern zugelassen, sodass der Speicher kein Problem sein sollte.

Ich habe eine Ebenengruppe mit maßstabsabhängigen Stilen. Die verschiedenen Schichten gehen von einfachen globalen Daten zu OSM über. Das Problem besteht darin, dass der Geoserver auf der globalen oder niedrigen Zoomebene zu versuchen scheint, alle Daten in allen Layern zu laden und zu verarbeiten, obwohl die meisten nicht gerendert werden. Wenn man OSM bedenkt, sind das viele Daten! Ich habe versucht, den Schmerz zu lindern, indem ich Ansichten von Daten mit niedrigem Zoom und Daten mit hohem Zoom erstellt habe (z. Dies hilft nicht und verschlimmert möglicherweise das Problem. Betrachtet man den Speicherverbrauch als Ganzes, zeigt HTOP, dass Java kaum einen der erlaubten 4 GB Heap verwendet. Es hilft also nicht, Speicher auf GeoServer zu werfen.

Die Ironie ist, dass das Rendering bei mittleren bis hohen Zoomstufen in Ordnung ist, obwohl jetzt die OSM-Daten sichtbar sind, vermutlich weil die angeforderten Daten viel begrenzter sind. Alle meine OSM-Layer sind räumlich indiziert und geclustert - hier also kein Problem. Dies sollte jedoch bei niedrigen Zoomstufen irrelevant sein, da die OSM-Ebenen in meinen Stilen nicht sichtbar sind.

Im Moment umgehe ich das Problem, indem ich meine Renderzeiten für WMS auf 1 Stunde setze und den Cache aussetze (sehr langsam - bis ich zu mittleren Zoomstufen komme, wenn die Datenlast auf vernünftige Mengen reduziert wird). Dies ist keine gute Lösung, insbesondere wenn ich eine kleine Änderung an meiner Ebenengruppe vornehme.

Ich möchte, dass eine einzelne Schichtgruppe die Dinge auf der Clientseite einfach hält. Die beste Lösung, wie ich es sehe, besteht darin, einen maßstabsabhängigen 'Switch' in der Layergruppendefinition zu implementieren, aber das erfordert eine Eingabe des GeoServer-Entwicklers. Welche praktischen Methoden schlagen die Leute jedoch vor, um die Leistung in der Zwischenzeit zu verbessern (ich habe bereits gelesenGeoServer auf Steroidenund dort alles relevante umgesetzt).

BEARBEITEN
Das Problem lag an einem beschädigten Stil, der dazu führte, dass auf allen Ebenen eine große Menge sehr kleiner Polygone gezeichnet wurde – was die beobachteten Ergebnisse erklärt. Festlegen des Stils, behebt das Problem. Dies hat jedoch einen scheinbar schwerwiegenden Speicherverlust nach Ausfällen aufgezeigt, der dazu führt, dass der Geoserver immer weniger reagiert und nur ein Neustart von Tomcat in Kombination mit einem unangenehmenkillall -9 JavaFixes aufrufen (einfach ein Neustart von Tomcat hinterlässt die Lecks, da die Überprüfung auf Lecks im Tomcat-Manager bestätigt).

In meinen Logs habe ich regelmäßig folgenden Fehler:

FEHLER [org.geotools.map] - Rufen Sie MapContent Dispos() auf, um Speicherlecks zu verhindern

Der Fehler wird nie einzeln, sondern immer mehrfach (manchmal zweistellig) gemeldet und ist insbesondere mit einigen DEBUG-Logs verbunden:

DEBUG [org.vfny.geoserver.responses.wms.map] - Einstellung auf transparent 2015-08-08 08:59:48,448 WARN [org.geotools.renderer.lite.gridcoverage2d] - Gittergeometrie innerhalb des gültigen Bereichsgrenzen: ReferencedEnvelope[-1.7976931348623157E308 : 1.7976931348623157E308, -85.0 : 85.0] Gittergeometrie isGridGeometry2D[GridEnvelope2D[6365… 7293, 7345… 7818],

und:

DEBUG [org.geoserver.security.IncludeQueryStringAntPathRequestMatcher] - Überprüfung der Übereinstimmung der Anfrage : 'Pfad: /web/, QueryString: x=0bkVEjecmbChX7z8UByFaQCm3CLIUMoGOhTdEK9-vGhb41MvY3jdSgYxGKt5; gegen '/web/**' 2015-08-09 16:39:43,123 DEBUG [org.geoserver.security.IncludeQueryStringAntPathRequestMatcher] - Übereinstimmender Pfad: /web/, QueryString: x=0bkVEjecmbChX7z8UByFaQCm3CLIUMoGOhTdEK9-vgXhndb*5 /** 2015-08-09 16:39:43,123 TRACE [org.geoserver.ows.OWSHandlerMapping] - Keine Handler-Zuordnung gefunden für [/web/] 2015-08-09 16:39:43,123 TRACE [org.geoserver. ows.OWSHandlerMapping] – Keine Handler-Zuordnung gefunden für [/web/] 2015-08-09 16:39:43,123 TRACE [org.geoserver.ows.OWSHandlerMapping] – Keine Handler-Zuordnung gefunden für [/web/] 2015-08- 09 16:39:43,123 TRACE [org.geoserver.ows.OWSHandlerMapping] – Keine Handler-Zuordnung gefunden für [/web/] 2015-08-09 16:39:43,126 DEBUG [org.geoserver] – Thread 1587 sperrt im Modus WRITE 2015-08-09 16:39:43,126 DEBUG [org.geoserver] - Thread 1587 hat die Sperre im Modus WRITE erhalten Speicherlecks verhindern

Diese Frage kann geschlossen werden, da sie sich jetzt vom GIS in die Programmierung verirrt hat und dies nicht das Forum dafür ist - ich werde die einzige Antwort als Lösung markieren.


Ciao, ein paar Dinge:

  • Mir scheint, dass Sie hauptsächlich Vektordaten rendern, daher hilft JAI überhaupt nicht

  • Wenn Sie hauptsächlich Vektordaten mit komplexen Stilregeln bereitstellen, hoffe ich, dass Sie ein DBMS anstelle von Shapefiles speziell für OSM verwenden. Wenn nicht auf globaler Ebene, muss GeoServer das gesamte Shapefile in den Speicher laden und dann filtern, da wir nur räumliche Indizes für Shapefiles haben

  • Wenn Sie ein räumliches DBMS verwenden, können Sie ausführliches Debugging und das von GeoServer erstellte SQL verwenden, damit Sie verstehen, ob Sie Ihre Daten neu strukturieren und/oder Stile vereinfachen müssen

  • Skalierungsbasierte Ausschlussregeln in SLDs werden vor dem Laden von Daten ausgewertet, sodass dies kein Problem darstellen sollte.

  • Wenn die Daten, die Sie auf globaler Ebene verwenden möchten, zu definiert sind (dh die Geometrien sind schwer zu laden und zu detailliert), würde ich vorschlagen, sie im Voraus zu vereinfachen, um die Renderzeit zu verkürzen (obwohl einige Vereinfachungen optimiert werden können, wenn Sie PGis direkt verwenden innerhalb der Layerdefinition)

  • Eine letzte Sache, Sie verwenden 2.8, das nicht offiziell veröffentlicht wurde (obwohl es zur Veröffentlichung geschlossen ist), daher könnten Sie auf Fehler stoßen :)

Simone.


Schau das Video: Intoduction To GeoServer