[OSM-dev] mod_tile memory leak?

Dylan Semler dylan.semler at gmail.com
Thu Jun 5 05:25:57 BST 2008


On Wed, Jun 4, 2008 at 4:57 PM, Jon Burgess <jburgess777 at googlemail.com>
wrote:

> The system monitor is a little crude. Most linux systems that have been
> running for any reasonable length of time will show nearly zero free
> memory. This is expected behaviour[1][2].


Yeah, I've heard it's crude and that measuring memory usage in Linux is not
as basic as it would seem.


> You suggest that you have to restart the renderd. If you don't do this,
> do you see anything bad happening?


After a few .meta tiles are generated I seem to start swapping heavily
(though now I'm not sure how accurate the swap monitor is).  After the z5
and z6 tiles were generated I restarted renderd to clear the memory and
swap.  The higher zoom levels then didn't seem to cause swapping at all.


> The code is used on the live OSM site rendering millions of tiles per
> day. It can use a fair amount of memory when it is running but I don't
> see it increasing over time (which would signify a leak).


Yeah, I thought about that.  This makes me think I don't know what I'm
talking about.

If you want to cut down the memory usage then you can make it single
> threaded: edit render_config.h to set NUM_THREADS to 1, then rebuild
> renderd.
>

Ahh, perhaps this answers it.  4 gigs of ram is enough for one z5 .meta
tile, but two being rendered at the same time causes swapping.  I guess for
some reason I had assumed that if it ran out of memory it would hold off
from rendering new tiles until others were finished to avoid using swap
space.  I don't know why I assumed this, it doesn't seem to make sense
(though might it be more efficient this way?).

Thanks for your help

-- 
Dylan

Type faster. Use Dvorak:
http://dvzine.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080605/1238d89e/attachment.html>


More information about the dev mailing list