In article <4aa91558.1040...@sspaeth.de> sebast...@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...@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...@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 blar...@scd.debian.net With Microsoft, failure is not an option. It is a standard feature. _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
