I am running GeoServer 2.8 on Ubuntu 14 as a WAR in Tomcat 7. I have an 8 core machine with 16GB of RAM and have allowed a generous Heap size of 4GB. I have JAI installed and enabled. Meta tiling is set to 8x4 and I have allowed 3GB for rendering so memory should not be a problem.
I have a layer-group with scale-dependent styles. The various layers transition from simple global data to OSM. The problem is that at the global or low-zoom levels, Geoserver seems to be attempting to load and process all data in all layers even though most will not be rendered. When you consider OSM - that is a LOT of data! I have tried to ease the pain by making views of low-zoom data and high-zoom data (e.g. for roads the low-zoom misses out a lot of the detail and minor roads). This does not help and possibly compounds the issue.
The strange thing is that, I don't really know what Geoserver is actually doing as JAI memory usage almost never rises above zero. I've seen it flicker briefly up to 1mb when rendering a global tile after sitting and apparently doing nothing for almost 1hr. Looking at memory consumption as a whole, HTOP shows that Java is barely using any of the 4GB heap allowed. So throwing memory at GeoServer doesn't help.
I suspect that Geoserver does not poll the styles of the layers in the group before attempting to process data. This is evident when I make a layer group of only the low-zoom data (two layers of Natural Earth data in my case for the global view). This simple layer group takes about 1 minute to render per tile compared 1 hour (!) for the full layer-group even though the results of the two renders are identical. The full layer-group includes all OSM data for Europe (but only rendered at mid to high zoom levels). This is why I think there is a need for polling the scales within styles or allowing max and min scales at the layer-group definition level so irrelevant layers can simply be ignored and thereby gain the speed-up seen in my experiment.
The irony is that rendering is fine at mid to high zoom levels, even though now the OSM data is visible, presumably as the data requested is much more limited. All my OSM layers are spatially indexed and clustered - so no problem here. Even so, that should be irrelevant at low zoom levels as the OSM layers are not visible in my styles.
At the moment I am working around the problem by setting my render times for WMS to 1 hr and seeding the cache (very slowly - until I get to intermediate zoom levels when the data load reduces to sane amounts). This is not a great solution, especially if I make a minor change to my layer-group.
I want a single layer-group to keep things simple at the client end. The best solution, as I see it, is to implement a scale-dependent 'switch' in the layer-group definition but that requires GeoServer-Developer input. However, what practical methods do people suggest to improve performance in the meantime (I have already read GeoServer on Steroids and implemented everything relevant in there).
أكثر...
I have a layer-group with scale-dependent styles. The various layers transition from simple global data to OSM. The problem is that at the global or low-zoom levels, Geoserver seems to be attempting to load and process all data in all layers even though most will not be rendered. When you consider OSM - that is a LOT of data! I have tried to ease the pain by making views of low-zoom data and high-zoom data (e.g. for roads the low-zoom misses out a lot of the detail and minor roads). This does not help and possibly compounds the issue.
The strange thing is that, I don't really know what Geoserver is actually doing as JAI memory usage almost never rises above zero. I've seen it flicker briefly up to 1mb when rendering a global tile after sitting and apparently doing nothing for almost 1hr. Looking at memory consumption as a whole, HTOP shows that Java is barely using any of the 4GB heap allowed. So throwing memory at GeoServer doesn't help.
I suspect that Geoserver does not poll the styles of the layers in the group before attempting to process data. This is evident when I make a layer group of only the low-zoom data (two layers of Natural Earth data in my case for the global view). This simple layer group takes about 1 minute to render per tile compared 1 hour (!) for the full layer-group even though the results of the two renders are identical. The full layer-group includes all OSM data for Europe (but only rendered at mid to high zoom levels). This is why I think there is a need for polling the scales within styles or allowing max and min scales at the layer-group definition level so irrelevant layers can simply be ignored and thereby gain the speed-up seen in my experiment.
The irony is that rendering is fine at mid to high zoom levels, even though now the OSM data is visible, presumably as the data requested is much more limited. All my OSM layers are spatially indexed and clustered - so no problem here. Even so, that should be irrelevant at low zoom levels as the OSM layers are not visible in my styles.
At the moment I am working around the problem by setting my render times for WMS to 1 hr and seeding the cache (very slowly - until I get to intermediate zoom levels when the data load reduces to sane amounts). This is not a great solution, especially if I make a minor change to my layer-group.
I want a single layer-group to keep things simple at the client end. The best solution, as I see it, is to implement a scale-dependent 'switch' in the layer-group definition but that requires GeoServer-Developer input. However, what practical methods do people suggest to improve performance in the meantime (I have already read GeoServer on Steroids and implemented everything relevant in there).
أكثر...