[OSM-dev] Alternative tile webserver needed?
nick at nickhill.co.uk
Sat Apr 28 13:02:16 BST 2007
Dirk-Lüder Kreie wrote:
> While it were possible to limit re-renderig of tiles (ie. don't render a
> tile if it has been rendered in the past X hours) but I'd rather not go
> down that path.
> If it helps I can donate a second 160 GB IDE drive to help spread the
> load out over several disks (ie. put the maplint layer on there).
Thank you for the offer. I will be visiting the servers hopefully in the first
half of next week. (I seem to have isolated a glitch problem in tests on the new
WRT updating tiles, there seems to be a problem which can be characterised as a
We have a very large data set and we are updating very small fragments of that
data set seemingly randomly. Assuming we can't find non-random elements to
leverage secondary level storage (RAM), we are limited by the random access seek
performance of the mass-storage medium.
Using a low latency (expensive) SCSI disk could increase seek throughput by a
factor of 3-4.
Adding another drive to spread the load will initially improve throughput by a
factor of 2. But to improve by another factor, we need 4, then 8, 16, 32.
Quickly becomes unworkable. However, adding drives does usefully increase
storage capacity, but negatively impacts system reliability. I'd suggest between
4 and 8 drives is a sweet spot for T at H.
Does the current T at H determine in advance of scheduling a tile to be rendered,
whether it has been dirtied since last rendered? An index to a list of 32 bit
INT checksums can be usefully cached in RAM, thereby skipping clean tiles in
More information about the dev