[Geocoding] Slow catching up

[Simon Nuttall]

Sarah,

many thanks for your continued support with our Nominatim installation.

I've added --index-instances 2 to the update call. The result seems
that the machine is even more i/o bound than before, with no
noticeable change to the cpu activity on the munin chart:

https://github.com/cyclestreets/nominatim-install/issues/7

It doesn't seem to be catching up any quicker than before.

Simon

On 26 January 2014 14:53, Sarah Hoffmann <lonvia at denofr.de> wrote:
> Hi Simon,
>
> On Sun, Jan 26, 2014 at 09:43:23AM +0000, Simon Nuttall wrote:
>> When I started the installation of a whole planet Nominatim, back in
>> early December the initial planet file was already 3 weeks old.
>>
>> This was compounded by having an invalid:
>>
>> /Nominatim/settings/configuration.txt
>>
>> left over from a previous import run, which I did not discover until
>> several weeks later.
>>
>> So when I fixed that Nominatim was about 6 weeks behind.
>>
>> It is going to take about 6 weeks to catch up because it seems to take
>> almost an hour to update an hour's changeset, eg these couple of lines
>> of output:
>>
>> 2014-01-26 09:18:42 Completed index step for 2013-12-05T13:29:02Z in
>> 26.8 minutes
>> 2014-01-26 09:18:42 Completed all for 2013-12-05T13:29:02Z in 45.85 minutes
>>
>> The machine is i/o bound.
>>
>> During setup.php I used --threads=2 which made things faster.
>>
>> Can more threads be used during update.php - eg I notice there is this option:
>>
>> --index-instances
>>
>> but would that make a difference?
>
> Using two threads will definitely make a difference although not as much as
> for the import. Going much beyond two threads is not really worth it because the
> threads interfere with each other quite a bit. In any case, if your system is
> live and serving queries, keep an eye on response times at busy times. Too many
> update threads might interfere there, too.
>
> Sarah
>



-- 
Simon Nuttall

Route Master, CycleStreets.net