On some installations, GeoServer will not start because an issue with GeoWebCache’s diskquotas. GeoWebCache is a component bundled with GeoServer that offers Time Map Service and Web Map Tile Service. Since these services might demand big amounts of disk storage, disk quotas are used to limit the amount of consumed storage [1, 2]. Thus, other services will not stop working because a lack of available storage.
Category: WMS cache
In this post we will see why the underlying file system used by Tilecache can be an issue because the high number of generated tiles.
Currently, main Linux distros use the Ext3 file system by default, which works with a fixed number of inodes and, hence, a limited number of files. In section 1 the problem is presented in more detail. In section 2 two ‘alternative’ file systems, JFS and XFS, less prone to run out of inodes, are presented.
1. “No space left on device”: running out of inodes.
TileCache can generate a large number of tiles. Let’s suppose we have a map resolution of 285 m/pixel, a scale quantization factor equal to 2, 10 zoom levels and that the cached area has 16,200 square km.; then, for each layer the number of tiles will be over 1,000,000. Say that for instance, we have 25 layers that must be cached; then, the grand total will be over 25,000,000 tiles. In case tiles are stored in the file system – cache types ‘Disk’ or ‘GoogleDisk’ -, the obvious problem we have to deal with is ensuring that the used file system will have room for all the tiles.
TileCache, as every piece of software complex enough, is not free of deficiencies. In this post I write about some TileCache features (or lack of) which, in my opinion, are deficiencies. These are: (a) a TileCache layer will only work with one set of map resolutions, (b) poor logging, (c) the TileCache seeder always stops on error, (d) the TileCache seeder cannot be restarted from a given point and (e) the lack of support for distributed computing. In some cases a workaround to partially overcome limitations is given.
TileCache version 2.11 is covered in this post.
1. Only one set of map resolutions per TileCache layer
By nature WMS caches work with finite sets of map resolutions. In my opinion, one deficiency of TileCache is that a layer will only work with one set of map resolutions. For each layer the set of map resolutions is set in the configuration file by using the parameter ‘resolutions’ or by giving both ‘maxResolution’ and ‘zoomLevels’ parameters.
The problem comes when you have to work with more than one set of map resolutions. Say you have a WMS layer named ‘municipalities-boundaries’ that it is cached and must be shown at two different sets of map resolutions, say one with max. map resolution 100 and the another one with map max. resolution 200. In this case, there would be two possible workarounds. One of them is creating two TileCache layers, say ‘municipalities-boundaries-200′ and ‘municipalities-boundaries-100′, as show in the following TileCache configuration file snippet:
Finally, we see what it seems a lighttpd
feature bug that prevents the TileCache debug log get written to lighttpd log file and how to override this issue.
1. TileCache logging
TileCache sends its debug output to the (standard error stream by default. This output includes information like the requested tile (its bounding box and x, y, z coords, where z represents the zoom level), time and whether it was a cache hit or cache miss. This information will be indispensable for debugging or estimating how much time the seeding of a WMS cache will last.
2. Configuring lighttpd to receive TileCache debug output
The very first step to get lighttpd receiving TileCache debug output is that TileCache generates debug output. In the TileCache configuration file the parameter debug must be set to ‘yes’ for every layer whose debug output we want to see.
[cache] type=Disk base=/mnt/geodata/tilecache/ [municipalities] debug=yes type=WMSLayer url=http://myserver/sdi-lugo?service=WMS&transparent=true extension=png size=256,256 bbox=580000,4688000,680000,4850000 layers=municipalities srs=EPSG:23029 extent_type=loose maxResolution=200 levels=10