[OSM-dev] what server next?

openstreetmap-dev at scd.debian.net openstreetmap-dev at scd.debian.net
Thu Sep 10 22:44:00 BST 2009


In article <4AA91558.1040909 at SSpaeth.de> Sebastian at SSpaeth.de writes:
>I would love to see more ROMAs and TRAPIs put in place (fast read only
>mirror), also XAPIs that allow convenient filtering might be nice)

As far as I can tell, it looks like a single Trapi server could handle
all t at h requests, if it could keep up to date reliably.  Unfortunatly,
it appears that a single consumer-grade SATA disk is no longer fast
enough to keep up with the number of updates beeing done.  Combined
with the problems generating change files (minute diffs are sometimes
delayed, especially when planet file is being generated -- hopefully
new dev will solve this) and the change files missing stuff, Trapi
hasn't been all that reliable lately.

I'm also running into some snags on the new version, that I hoped to
have ready months ago.  One appears to be a perl bug, and the other is
in the fastcgi that only occurs on one of the two systems I've tested
on.

For a new Trapi server, I think the following is minimal:
fast net connection that can handle large volume
fast disk: raid0 of 3 or more drives, or enterprise SSD.  100GB is enough.
(additional 100GB or more of slow disk is also useful for planet files and logs)
2GB memory.  More is better.
2Ghz cpu.  Faster/additional cpu has some, but not much, impact.


(The first requrement is dropped if you are only running Trapi for a
local render farm.  I found Trapi used less bandwidth to keep updated
than a couple of t at h renderers.)

Note that there isn't any particular reason to colocate with other OSM
servers, other than Mat's load-ballancer if that isn't replaced.

-- 
Blars Blarson			blarson at scd.debian.net

With Microsoft, failure is not an option.  It is a standard feature.




More information about the dev mailing list