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 [email protected] http://www.remote.org/jochen/ +49-721-388298 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
