[OSM-dev] Tirex Bucket Configuration
Jochen Topf
jochen at remote.org
Wed Jun 15 08:33:57 BST 2011
On Wed, Jun 15, 2011 at 06:09:13PM +1200, Adam Ratcliffe wrote:
> We've been using mod_tile/renderd for approx. a year serving an
> australasian tile set, we will only be serving this one tile set for
> the foreseeable future. We're now looking at rebuilding our tile
> servers and I have set up a test installation running Tirex.
>
> I'm wondering if anybody is able to provide me with any guidelines on
> how to configure the buckets. Is there a relationship between the
> maxproc setting and the number of CPUs available on the host for
> instance?
All of this of course depends on the details of your hardware, the map data
you have, the number of tiles, the access pattern etc. But here are some
points to get you started:
* You probably don't want to have too many rendering processes even if you
have many CPUs, because then your bottleneck will be the database disk
access.
* You also, of course, don't want to few rendering processes, because you
don't want an idle machine.
* You should not use all capacities in the low priority buckets, so that
there are always capacities available if high priorities come in.
* For the highest priority bucket, your maxproc should probably be slightly
higher than the number of CPUs you have. Slightly higher because some processes
will be waiting for IO. Maxload about twice that (1 for the renderer
process, 1 one for the datatabase process).
* For all other buckets use less. Numbers depend on your ratio of interactively
rendered tiles vs. background-rendered tiles. If you want snappier access
for live rendering give low-priority buckets smaller maxproc/maxload, but
background-rendering will be slower.
Start with those ideas and then watch your system and change settings
accordingly. Look at the jobs.log logfile for rendering times and success
rate. Experiment with different settings.
Jochen
--
Jochen Topf jochen at remote.org http://www.remote.org/jochen/ +49-721-388298
More information about the dev
mailing list