On -10/01/37 20:59, Peter Körner wrote:
but renderd had a hard limit of 1000 tiles in the queue.
For completeness sake, I thought I'd mention that you can change that
limit quite easily. Simply change the constant at
On Sat, Oct 02, 2010 at 01:28:48PM +0100, Kai Krueger wrote:
On -10/01/37 20:59, Peter Körner wrote:
but renderd had a hard limit of 1000 tiles in the queue.
For completeness sake, I thought I'd mention that you can change that
limit quite easily. Simply change the constant at
Am 02.10.2010 14:28, schrieb Kai Krueger:
On -10/01/37 20:59, Peter Körner wrote:
but renderd had a hard limit of 1000 tiles in the queue.
On the main OSM tile server, I believe, that limit is still there as a
feature rather than a bug.
Our starting point was that we have a very little
Am 28.09.2010 16:58, schrieb Samir Faci (Dev):
When I tried to use render_list to regenerate all the usual tiles
(that I care about 0-13).
It gets to up to lvl 10 then almost dies. When I tried to run just
level 10 it dies almost immediately.
renderd is not able to handle such big queues. In
On Wed, 2010-09-29 at 08:20 +0200, Peter Körner wrote:
Am 28.09.2010 16:58, schrieb Samir Faci (Dev):
When I tried to use render_list to regenerate all the usual tiles
(that I care about 0-13).
It gets to up to lvl 10 then almost dies. When I tried to run just
level 10 it dies almost
Am 29.09.2010 10:10, schrieb Jon Burgess:
I'm not sure what went wrong for you but the main OpenStreetMap server
regularly runs with the queue full of 1000 requests. I'm not aware of
any fundamental problems in renderd with handling this level of load.
We started with a very small number of
Aside from this one occurrence, I haven't had any issues with renderd,
at least not in regards to queue time.
render_list does seem to have a bug where it ignores the -l,
--max-load=LOAD value. Though I need to look at it a bit more to see
why its not using the value, I'm passing.
Now, I do
Samir Faci (Dev) wrote:
render_list does seem to have a bug where it ignores the -l,
--max-load=LOAD value. Though I need to look at it a bit more to see
why its not using the value, I'm passing.
My guess would be the check_load() call needs to happen in the dequeueing
path rather than
On Wed, 2010-09-29 at 07:31 -0700, Kai Krueger wrote:
Samir Faci (Dev) wrote:
render_list does seem to have a bug where it ignores the -l,
--max-load=LOAD value. Though I need to look at it a bit more to see
why its not using the value, I'm passing.
My guess would be the
I've been poking at this for a while, so I figured I should ask much
brighter people about the topic.
I downloaded and applied a recent planet file using slim mode.
planet-100922.osm.bz2MD5: 04327dc409fe4a2a23130ec265fe6703
When I tried to use render_list to regenerate all the usual tiles
On Tue, 2010-09-28 at 09:58 -0500, Samir Faci (Dev) wrote:
(gdb) bt
#0 0x76f5da75 in raise () from /lib/libc.so.6
#1 0x76f615c0 in abort () from /lib/libc.so.6
#2 0x778138e5 in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/libstdc++.so.6
#3
I have renderd installed as a service.
I'm on the latest version checkout from:
http://github.com/openstreetmap/mod_tile.git
Running on Ubuntu Lucid, 64bit.
I usually render using one of these commands:
/usr/bin/render_list -v --all -n 4
--socket=/var/run/renderd/renderd.sock --min-zoom=0
On Fri, 2010-07-23 at 12:40 -0500, Samir Faci (Dev) wrote:
I have renderd installed as a service.
I'm on the latest version checkout from:
http://github.com/openstreetmap/mod_tile.git
Running on Ubuntu Lucid, 64bit.
I usually render using one of these commands:
/usr/bin/render_list
13 matches
Mail list logo
