User:SomeoneElse/Tuning renderd memory usage

Once you've set up a tile server, you may find yourself asking "what on earth is it doing and why are my tiles being rendered so slowly". The likely reason, at least initially, is that it's busy producing detailed low zoom level tiles that you've previously asked for before zooming in on an area that you're interested in.

Assuming you've already got renderd set up and writing to "syslog", to see what it is currently doing, run the following.

• sudo tail -f /var/log/syslog | grep " TILE"

You should see both "START TILE" and "DONE TILE" messages. The "START TILE" ones show how old the previous tile was, and the "DONE TILE" ones show how long it took to produce the tiles for each request:

Oct 19 11:49:04 ubuntuvm38 renderd[6663]: DEBUG: START TILE default 6 16-23 16-23, new metatile Oct 19 11:49:11 ubuntuvm38 renderd[6663]: DEBUG: DONE TILE default 6 16-23 16-23 in 7.276 seconds

(notice how each request is for several tiles)

You'll only see request for tiles that renderd thinks that it needs to produce, of course - if it thinks that a tile has not changed since it was last rendered, it won't bother. Similarly, if a tile is cached in your web browser, then the request may not even get to your web server.

By default renderd will try to produce 4 sets of tiles at the same time, because of this setting in /usr/local/etc/renderd.conf :

• num_threads=4

If you find that the total memory usage is too high (in my case I'm using VMware, and can easily look at the guest memory usage in the VMware client) then consider reducing that number. Requests are queued, so you won't miss rendering tiles - it just won't try and do quite as many at the same time.

Note that total memory usage on a tile server is likely to be dominated by postgres rather than by renderd, and reducing the number of threads that renderd runs won't affect that directly. If you have a problem just with postgres, you'll need to go back and try a smaller import.