[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