[OSM-talk] dev server: the end is nigh!
Frederik Ramm
frederik at remote.org
Fri May 4 10:23:09 BST 2007
Hi,
Nick has alrady mentioned that the dev server is on it's last
legs. To corroborate that claim, I'd like to point to these Munin
graphs showing (in pink) the percentage of time spent by the
processor waiting for - mostly disk - I/O:
http://www.openstreetmap.org/munin/openstreetmap/dev.openstreetmap-
cpu.html
The long-time average is over 50%. A normally running server would
average 1% "iowait", for example our tile server:
http://www.openstreetmap.org/munin/openstreetmap/tile.openstreetmap-
cpu.html
db is at around 15% which means it is heavily used but still good:
http://www.openstreetmap.org/munin/openstreetmap/db.openstreetmap-
cpu.html
May I suggest that everybody who runs anything that requests tiles in
an automated fashion, thinks about wheter this is really useful/
necessary, and whether the access frequency could perhaps be reduced?
I will refrain from running any automated tile update jobs as long as
the server is in this condition - a current slippymap is not worth
anything if the tiles don't get served ;-(
How can we solve the problem? I could image that more RAM would allow
more caching and thus less disk I/O. A second disk and an intelligent
way of distributing requests to the tile repository (maybe a simple
RAID-0) could also help, as could faster disks. But I am (a) not a
hardware expert and (b) too far away, so I hope that Nick Hill has an
idea and just tells us what is needed, and then we can go look for
resources.
Bye
Frederik
--
Frederik Ramm ## eMail frederik at remote.org ## N49°00.09' E008°23.33'
More information about the talk
mailing list