[OSM-dev] Proposal: Database accelerator and dirty tile marker based on simple algorithm.
Nick Hill
nick at nickhill.co.uk
Thu Sep 21 11:07:35 BST 2006
Hello Andy
The server isn't being powered down.
Each tile rendering request is spawning a new process up to a limit set
in apache. That process will normally live until until that tile has
rendered. If the number of processes is not beyond max_servers, the
process will live to serve another request.
The more tiles we have in the process list, the longer it takes for each
tile to render. The longer it takes for each tile to render, the more
tile renderers end up in the process list. This gets to a point where
the processes leave almost no CPU capacity for other functions, and use
all available memory.
At these points, munin is not able to register system status; there is
not enough CPU power or memory to respond to the munin request. At these
times, it appears the system is turned off.
Ideally, we need a given number of rendering processes operating
asynchronously from incoming requests. Rendering processes should not be
queued, instead, rendering requests should be queued. This will optimise
use of CPU cycles, memory and db.
We need:
1) A good tile invalidation system. Tiles should be cached until marked
dirty.
2) Asynchronous tile rendering processes. Asynchronous from incoming
requests.
3) A system to determine popular tiles. These should be speculatively
re-rendered after being marked dirty when the system is quiet so they
will already be rendered when a user asks for them.
Andy Robinson wrote:
> Nick,
>
> The Munin graphs appear to show the server being powered down or at least
> not talking to the Munin log quite a lot throughout this week. Most
> noticeable on the cpu plots. Is there a specific reason for that? The
> behaviour is not there on previous weeks.
>
More information about the dev
mailing list