3

I'm looking to run an OSM tile server and have been wondering what spec machine to get. I expect fairly heavy usage across a full planet of data and have taken the current yevaud spec as a benchmark of a high usage web-server.

http://wiki.openstreetmap.org/wiki/Servers/yevaud

My only question on this is what is the SSD disk used for in particular setup? it's not big enough to cover the storage of the tiles (stated at ~1.2Tb). What is being kept on this disk? the disk itself would seem to represent half the cost of the server.

asked 12 Apr '12, 22:08

John%20Perrin's gravatar image

John Perrin
76227
accept rate: 0%


3 Answers:
3

You need the SSD for the PostGIS tablespace in order to be able to quickly render tiles when somebody requests them. Remember, a tile server is not a passive component that just hands out tiles - they will often have to be computed on the fly.

permanent link

answered 12 Apr '12, 22:33

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
73.3k866641137
accept rate: 24%

Thanks! So this will hold the data files that are downloaded from planet.osm? That's actually a relief as i thought I was going to have to recreate Smaug as well!

(12 Apr '12, 22:36) John Perrin

You don't need Smaug, but you do need a database on the tile server itself. You will download the planet file and process it with osm2pgsql, whereby it will be written to the PostGIS database and onto the SSD. This will currently require about 280 GB of SSD space - less if you don't want updates, more if you want to add extra columns that are not in the standard OSM style.

(12 Apr '12, 22:46) Frederik Ramm ♦
3

There are two main components to the storage system of a tile server, each of which can have different requirements depending on the circumstances

1) Tile storage cache

For the tile storage usually one needs quite a bit of space, but performance isn't quite as critical. For a general purpose world wide map you will likely need somewhere on the order of above 600 GB. The full world wide tile set is considerably larger than that, but rendering on the fly of e.g. z18 ocean tiles is usually possible without too much problems. I don't know the exact scaling, but it seems like above somewhere between 300 - 600 GB the cache hit rate only increases slowly with size of the cache.

Performance wise, it appears like 1000 tiles/s will generate somewhere on the order of 300 - 500 iops on the disk system, although that obviously depends on the size of ram of the server and the distribution of areas served. This is a level of performance that you can probably get out a raid array of a few sata disks. The performance requirement on this part of the disks likely scale fairly straightforward with the number of tiles served per second. Adding a reverse proxy in front of the tile server can also help reasonably to distribute load for tile serving. For most tile servers I have seen so far tile serving hasn't really been much of an issue, but in the order above 1000 Tiles/s you probably do need to consider it as well.

2) Rendering database

The rendering database is where for most people the disk performance bottlenecks are. For the full planet, the postgis database with indexes is around 300 - 400GB in size. This is as others have pointed out where some people use SSDs for. Quite a bit of performance is consumed in keeping the database up to date with minutely diffs from OSM. This performance does not depend at all on how many tiles you serve, but only the rate of editing in OSM. From what I have seen (and other might correct me), a 2 - 4 disk sata raid array might not be able to keep up with edits during absolute peak editing times (e.g. Sunday afternoon European time), but should catch back up during the night. On top of that is the actual rendering of tiles. As typically one doesn't re-render tiles in advance (other than low zoom tiles), but only once they are actually viewed. Rendering performance does to some degree depend on the tile serving performance. If it doesn't matter how up to date rendered tiles are, rendering requests can be queued and rendered during quiet periods, which considerably reduces the performance requirements on the database.

So overall whether you need an SSD for the database mostly depends on how up-to-date you want to me with respect to OSM edits. If you want to be in the order of minutes behind OSM, you probably will need an SSD. Given that a fast update is important for mappers as reward for their work, the SSD in osm's tile server has been a big win. If daily updates or less are fine, then you might not need one. Once you get down to monthly updates, you are likely best not using an "updateable database" but do full reimports, the size of the database reduces typically to less than half the size.

It also depends on how spatially distributed your requests are. If e.g. your site has a "bunch of locations" around which it displays local maps. I.e. the same locations are shown over and over again, the rendering load is much less than if you offer "Downloading country wide tiles for offline use in a mobile app" even with the same amount of serving load.

If you don't need a world wide map, then hardware requirements also considerably reduce and once you get down to only e.g. a country like e.g. Italy or the UK, you possibly don't really have to worry about the database anymore at all, as any modern hardware is probably sufficient.

permanent link

answered 13 Apr '12, 02:42

apmon's gravatar image

apmon
6.3k184456
accept rate: 20%

@apmon - I know this is old, but wondering if you could elaborate on optimizing IOPS for the SSD. You mention 300 - 500 IOPS for storage cache, but what is that also sufficient for the rendering database disk? I am considering using a AWS SSD with pre-provisioned IOPS. They make you pay for IOPS as well as storage so I don't want to over do it, but also don't want a bottleneck.

(29 May '17, 05:19) rgwozdz
0

Hi,

I'm trying to instal my own OSM server but it always fails at full disk. I have this server https://www.hetzner.de/de/hosting/produkte_rootserver/ex51ssd with 500GB SSD. I have tried to import the DB for whole planet without slim tables but there is not enough RAM, and also with flat-nodes but no luck. Please can somebody write here what are current server requirements? What size of disk it needs for successful import and also some raw estimate for cache size?

Thank you very much.

permanent link

answered 15 Dec '16, 09:33

mariansedivy's gravatar image

mariansedivy
111
accept rate: 0%

edited 15 Dec '16, 15:51

Are you running a full planet import? Or only a specific country/city?

(15 Dec '16, 12:32) scai ♦

Hi, I want full planet.

(15 Dec '16, 12:50) mariansedivy
1

Please see if these are helpful for you. servers and servers

(16 Dec '16, 03:32) Gagan

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×104
×15

question asked: 12 Apr '12, 22:08

question was seen: 13,791 times

last updated: 29 May '17, 05:36

powered by OSQA