<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks for this great response Kai, it's incredibly useful.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>John<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Ian Dees [mailto:ian.dees@gmail.com] <br>
<b>Sent:</b> 13 April 2012 03:05<br>
<b>To:</b> Kai Krueger<br>
<b>Cc:</b> dev@openstreetmap.org<br>
<b>Subject:</b> Re: [OSM-dev] Yevaud SSD Drive<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>This is a great writeup, Kai. I hope you throw it on the
wiki or something.<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>I'll throw in my 2 cents: The OSM US tile server has a
worldwide osm2pgsql database set up for experimental rendering. It has almost
no tile rendering load (because it's not really doing anything notable yet) and
I had it updating every 2 hours before the diff location changed. It has four
600GB WD Velociraptor disks in a RAID10 set up and was usually able to catch up
those 2 hours in 15-30 minutes.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>On Thu, Apr 12, 2012 at 8:39 PM, Kai Krueger <<a
href="mailto:kakrueger@gmail.com">kakrueger@gmail.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal>There are two main components to the storage system of a
tile server,<br>
each of which can have different requirements depending on the circumstances<br>
<br>
1) Tile storage cache<br>
<br>
For the tile storage usually one needs quite a bit of space, but<br>
performance isn't quite as critical. For a general purpose world wide<br>
map you will likely need somewhere on the order of above 600 GB. The<br>
full world wide tile set is considerably larger than that, but rendering<br>
on the fly of e.g. z18 ocean tiles is usually possible without too much<br>
problems. I don't know the exact scaling, but it seems like above<br>
somewhere between 300 - 600 GB the cache hit rate only increases slowly<br>
with size of the cache.<br>
<br>
Performance wise, it appears like 1000 tiles/s will generate somewhere<br>
on the order of 300 - 500 iops on the disk system, although that<br>
obviously depends on the size of ram of the server and the distribution<br>
of areas served. This is a level of performance that you can probably<br>
get out a raid array of a few sata disks. The performance requirement on<br>
this part of the disks likely scale fairly straightforward with the<br>
number of tiles served per second. Adding a reverse proxy in front of<br>
the tile server can also help reasonably to distribute load for tile<br>
serving. For most tile servers I have seen so far tile serving hasn't<br>
really been much of an issue, but in the order above 1000 Tiles/s you<br>
probably do need to consider it as well.<br>
<br>
2) Rendering database<br>
<br>
The rendering database is where for most people the disk performance<br>
bottlenecks are. For the full planet, the postgis database with indexes<br>
is around 300 - 400GB in size. This is as others have pointed out where<br>
some people use SSDs for. Quite a bit of performance is consumed in<br>
keeping the database up to date with minutely diffs from OSM. This<br>
performance does not depend at all on how many tiles you serve, but only<br>
the rate of editing in OSM. From what I have seen (and other might<br>
correct me), a 2 - 4 disk sata raid array might not be able to keep up<br>
with edits during absolute peak editing times (e.g. Sunday afternoon<br>
European time), but should catch back up during the night. On top of<br>
that is the actual rendering of tiles. As typically one doesn't<br>
re-render tiles in advance (other than low zoom tiles), but only once<br>
they are actually viewed. Rendering performance does to some degree<br>
depend on the tile serving performance. If it doesn't matter how up to<br>
date rendered tiles are, rendering requests can be queued and rendered<br>
during quiet periods, which considerably reduces the performance<br>
requirements on the database.<br>
<br>
So overall whether you need an SSD for the database mostly depends on<br>
how up-to-date you want to me with respect to OSM edits. If you want to<br>
be in the order of minutes behind OSM, you probably will need an SSD.<br>
Given that a fast update is important for mappers as reward for their<br>
work, the SSD in osm's tile server has been a big win. If daily updates<br>
or less are fine, then you might not need one. Once you get down to<br>
monthly updates, you are likely best not using an "updateable
database"<br>
but do full reimports, the size of the database reduces typically to<br>
less than half the size.<br>
<br>
It also depends on how spatially distributed your requests are. If e.g.<br>
your site has a "bunch of locations" around which it displays local<br>
maps. I.e. the same locations are shown over and over again, the<br>
rendering load is much less than if you offer "Downloading country wide<br>
tiles for offline use in a mobile app" even with the same amount of<br>
serving load.<br>
<br>
If you don't need a world wide map, then hardware requirements also<br>
considerably reduce and once you get down to only e.g. a country like<br>
e.g. Italy or the UK, you possibly don't really have to worry about the<br>
database anymore at all, as any modern hardware is probably sufficient.<br>
<br>
Kai<br>
<br>
On 04/12/2012 03:53 PM, Paul Norman wrote:<br>
> I believe the SSD is used for the database. Before the SSD the DB was on<br>
> the RAID10 array. I’m not sure four 300 GB 10k RPM drives are much<br>
> cheaper than a SSD.<br>
><br>
><br>
><br>
> You might find looking through munin for yevaud helpful -<br>
> <a
href="http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/#disk"
target="_blank">http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/#disk</a><br>
><br>
> The SSD is sdd according to the wiki.<br>
><br>
><br>
><br>
> How many tiles do you expect each map view to generate? I’d expect
at<br>
> least 50-100. This would give you an average of 200-500 requests/second.<br>
> Just for comparison, the caches in front of yevaud peak at about 3.5k<br>
> requests/second<br>
><br>
><br>
><br>
> *From:*John Perrin [mailto:<a href="mailto:john.d.perrin@gmail.com">john.d.perrin@gmail.com</a>]<br>
> *Sent:* Thursday, April 12, 2012 2:34 PM<br>
> *To:* <a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
> *Subject:* [OSM-dev] Yevaud SSD Drive<br>
><br>
><br>
><br>
> Hi,<br>
><br>
><br>
><br>
> I've posted this question on the OSM Q & A site a well, not sure what<br>
> the best forum for the question is, so please forgive the dual post if<br>
> you also follow that site.<br>
><br>
><br>
><br>
> Basically, I was just inquiring into the specific need for the SSD drive<br>
> on the yevaud tile server. I'm looking to run an OSM tile server
that<br>
> can handle roughly 200,000 - 400,000 map views a day and have taken this<br>
> as a good benchmark for the server spec. However the SSD is half the<br>
> cost of reproducing a server with that spec. I was just wondering<br>
> exactly what the disk was used for, and why is specifically needed the<br>
> SSD drive. I can see the purchase logged in the server upgrade history,<br>
> but I can't see any reason explaining why it was needed.<br>
><br>
><br>
><br>
> Thanks<br>
><br>
><br>
><br>
> John<br>
><br>
<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>