[Geoserver-users] ImagePyramid performance with more than 10'000 tiles

Hi

We are serving some aerial images with the ImagePyramid plugin. Tiling was done with gdal_retile: 2000x2000px, Geotiff with LZW compression and alpha channel. Performance is really nice but from time to time it takes 10 or more seconds to deliver the wms request. This happens only when Geoserver has to use the 0 level tiles where we have 11'144 tiles. Can the amount of tiles in one single directory be a issue? CPU load is not increasing during the request.

I'm running GeoServer 2.1.1 on a root server with 4 cores, enough memory and a software raid. Any guess what happens? Thanks.

Regards
Stefan

Freundliche Grüsse
Stefan Ziegler
Leiter amtliche Vermessung

Amt für Geoinformation
Amtliche Vermessung
Rötistrasse 4
4500 Solothurn

Telefon +41 32 627 75 96
Telefax +41 32 627 75 98
stefan.ziegler@anonymised.com
http://www.so.ch

Hi Stefan,

On Tue, Sep 6, 2011 at 5:40 PM, Ziegler Stefan <Stefan.Ziegler@anonymised.com> wrote:

We are serving some aerial images with the ImagePyramid plugin. Tiling was done with gdal_retile: 2000x2000px, Geotiff with LZW compression and alpha channel. Performance is really nice but from time to time it takes 10 or more seconds to deliver the wms request. This happens only when Geoserver has to use the 0 level tiles where we have 11’144 tiles. Can the amount of tiles in one single directory be a issue? CPU load is not increasing during the request.

What filesystem are you using? If it’s ext4/xfs/jfs/etc then you’ll be fine. For ext3, check that btree directory indexing is enabled - run “sudo tune2fs -l /dev/sdaX | grep Features” and look for “dir_index”. For ext2 you’re out of luck.

Rob :slight_smile:

On Tue, Sep 6, 2011 at 7:40 AM, Ziegler Stefan <Stefan.Ziegler@anonymised.com> wrote:

Hi

We are serving some aerial images with the ImagePyramid plugin. Tiling was done with gdal_retile: 2000x2000px, Geotiff with LZW compression and alpha channel. Performance is really nice but from time to time it takes 10 or more seconds to deliver the wms request. This happens only when Geoserver has to use the 0 level tiles where we have 11'144 tiles. Can the amount of tiles in one single directory be a issue? CPU load is not increasing during the request.

Yes, it can be an issue. The pyramid is just a stacked set of mosaics,
so the pyramid just delegates to the
mosaic readers.
Each mosaic is cached in a soft cache, meaning it can be garbage
collected and in need of being reloaded.
On reload the mosaic will take the shapefile index and load it in
memory, which in the case of a large mosaic
migth take time.

Try adding:
Caching=false
in each and every property file of the mosaics, this should make the
mosaic not load the tile index in memory,
but query on disk every time, which should prevent the 10 seconds
delay (it will of course have a toll on each
request, querying on disk is slower than hitting the in memory index).

There is also the issue of having to open all those little files, in
general it's bad practice to slice information
in a ton of tiny files. Pyramid generated with tools like gdal_retile,
using the default settings,
might be useful for tile caches but in general it's much better to
setup the mosaics with (very) large files
and overviews, and keep low both the number of levels and the number of files.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Hi Andrea,
  Not to butt in on the conversation, but I am curious about
optimization of ImagePyramids: Could you please define --very-- big files.
Are we talking files near the 2GB ceiling for GeoTiff?

Thanks,
Steve

Stephen Mather
Geographic Information Systems (GIS) Manager
(216) 635-3243
svm@anonymised.com
clevelandmetroparks.com

-----Original Message-----
From: Andrea Aime [mailto:andrea.aime@anonymised.com]
Sent: Tuesday, September 06, 2011 2:34 AM
To: Ziegler Stefan
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] ImagePyramid performance with more than
10'000 tiles

On Tue, Sep 6, 2011 at 7:40 AM, Ziegler Stefan <Stefan.Ziegler@anonymised.com>
wrote:

Hi

We are serving some aerial images with the ImagePyramid plugin. Tiling was

done with gdal_retile: 2000x2000px, Geotiff with LZW compression and alpha
channel. Performance is really nice but from time to time it takes 10 or
more seconds to deliver the wms request. This happens only when Geoserver
has to use the 0 level tiles where we have 11'144 tiles. Can the amount of
tiles in one single directory be a issue? CPU load is not increasing during
the request.

Yes, it can be an issue. The pyramid is just a stacked set of mosaics,
so the pyramid just delegates to the
mosaic readers.
Each mosaic is cached in a soft cache, meaning it can be garbage
collected and in need of being reloaded.
On reload the mosaic will take the shapefile index and load it in
memory, which in the case of a large mosaic
migth take time.

Try adding:
Caching=false
in each and every property file of the mosaics, this should make the
mosaic not load the tile index in memory,
but query on disk every time, which should prevent the 10 seconds
delay (it will of course have a toll on each
request, querying on disk is slower than hitting the in memory index).

There is also the issue of having to open all those little files, in
general it's bad practice to slice information
in a ton of tiny files. Pyramid generated with tools like gdal_retile,
using the default settings,
might be useful for tile caches but in general it's much better to
setup the mosaics with (very) large files
and overviews, and keep low both the number of levels and the number of
files.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

----------------------------------------------------------------------------
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Tue, Sep 6, 2011 at 7:36 PM, Stephen V. Mather
<svm@anonymised.com> wrote:

Hi Andrea,
Not to butt in on the conversation, but I am curious about
optimization of ImagePyramids: Could you please define --very-- big files.
Are we talking files near the 2GB ceiling for GeoTiff?

Yes. And when GeoServer 2.2.0 will be out, or if we can backport imageio-ext
1.1 usage to the 2.1.x series, even above that limit, imageioext-ext 1.1
will allow us to support BigTIFF.
If memory serves me right we tested a single 100GB tiff file (a bit on
the large side)
and it was no slower than the equivalent mosaic made of 4GB files.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

From: Andrea Aime [mailto:andrea.aime@anonymised.com]
Yes. And when GeoServer 2.2.0 will be out, or if we can
backport imageio-ext
1.1 usage to the 2.1.x series, even above that limit,
imageioext-ext 1.1 will allow us to support BigTIFF.
If memory serves me right we tested a single 100GB tiff file
(a bit on the large side) and it was no slower than the
equivalent mosaic made of 4GB files.

We are currently experimenting with a 28GB external overview (GeoTIFF
.ovr) by using an updated imageio-ext-tiff needed for (>4GB files) and
it seems to work just fine.

_________________________________________
Fredrik Holmqvist, Metria AB www.metria.se