[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