[Geocoding] Nominatim machine spec

[Sarah Hoffmann]

The minimum amount of RAM for a planet-wide installation is 32GB,
below that you'll see a significant slowdown. For running the
server there is no fixed limit, postgres will make due with
what it gets. The more RAM you have, the less IO. Still, I'd
also plan at least 32GB.

If you want to run Nominatim on a shared server, the factor that
is really limiting is IO. I strongly recommend getting an SSD
with at least 400GB. That is not enough for the complete DB but
sufficient to get the important indexes for search on a fast disk.
The upcoming version of Nominatim will have support for scattering
the DB across multiple tablespaces, so that a setup with a smaller
SSD is less of a pain. In any case, you sould consider having
the DB on separate disks so that even when Nominatim somehow
ends up doing heavy IO, your other application remains responsive.
In total you need to plan at least 800GB without and 1.2TB with
Tiger address data in terms of disk space.

Once the IO problem is solved, updates are not really heavy at all.
They can be run quitely in the background with 1 or 2 threads and
will take up far less than 1 CPU.

For the search-as-you-type stuff, have you considered running
Photon[1] instead of Nominatim directly? It has matured quite
a bit in the last year and Komoot even provides dumps, so that
the hardware requirements are significantly lower. There are
two small disadvantages: it cannot do minutely updates yet
and language support is limited (only name and name:{en,de,fr,it}).

Sarah

[1] https://github.com/komoot/photon

On Fri, Feb 27, 2015 at 05:05:17PM +0000, Simon Nuttall wrote:
> Hi Sarah,
> 
> For serving geocodes, we don't get very many requests, only a few
> (less than ten) per second at most, and less than that in the main.
> 
> We do some of our own caching and detect postcodes and railway
> stations ourselves.
> 
> We do like to use search-as-you-type which is a good reason why we
> want to run our own service and so we don't use the public nominatim.
> 
> The main concern is how much hogging of the machine would be caused by
> it constantly updating. When we were on a VM it could not cope, so
> obviously that is a concern for us.
> 
> Simon
> 
> On 27 February 2015 at 16:08, Sarah Hoffmann <lonvia at denofr.de> wrote:
> > Hi Simon,
> >
> > what are your requirements performance-wise? How many requests do you
> > get at the moment?
> >
> > Sarah
> >
> > On Fri, Feb 27, 2015 at 03:41:16PM +0000, Simon Nuttall wrote:
> >> We're trying to spec up a new machine to run CycleStreets and we would
> >> like to instantiate a worldwide Nominatim service too.
> >>
> >> Our current Nominatim service (which runs in a VM) is now getting
> >> quite out of date as I stopped updating it when it couldn't keep up
> >> with the updates and was hogging the disk.
> >>
> >> Our new machine will not be a VM, and I think it will be able to run
> >> alongside CycleStreets in the same bare metal Ubuntu installation,
> >> their main common element will be apache2.
> >>
> >> My question relates to how much RAM is used by a world-wide Nominatim
> >> when it has finished it's initial set up. Does it need to have a big
> >> permanently allocated RAM image to operate efficiently? If so how big
> >> is that RAM image?
> >>
> >> Will the updating be a significant drain on the performance of the
> >> machine overall?
> >>
> >> Is there a big RAM requirement during the initialization phase?
> >>
> >> Although we're considering getting a machine with 128GB RAM for
> >> CycleStreets an alternative option is to get a separate dedicated
> >> smaller machine that only has 16GB. Could that do the whole world
> >> (presumably taking much longer for the initialization phase), but fine
> >> once it has got through that?
> >>
> >> Simon
> >>
> >> --
> >> Simon Nuttall
> >>
> >> Route Master, CycleStreets.net
> >>
> >> _______________________________________________
> >> Geocoding mailing list
> >> Geocoding at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/geocoding
> 
> 
> 
> -- 
> Simon Nuttall
> 
> Route Master, CycleStreets.net