This is a great writeup, Kai. I hope you throw it on the wiki or something.<div><br></div><div>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.</div>
<div><br><div class="gmail_quote">On Thu, Apr 12, 2012 at 8:39 PM, Kai Krueger <span dir="ltr"><<a href="mailto:kakrueger@gmail.com">kakrueger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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><br>
</blockquote></div><br></div>