Areas calculation takes more than 86400. timeout occurrs

[jwest75674]

Firstly, I've set dispatcher to a very large time allottment, like --time=864000000000

See:

dispatcher --status
Number of not yet opened connections: 0
Number of connected clients: 2
Rate limit: 30
Total available space: 12884901888
Total claimed space: 4294967296
Average claimed space: 0
Total available time units: 4294967295
Total claimed time units: 0
Average claimed time units: 0
Counter of started requests: 1
Counter of finished requests: 0
202 2618 0 4294967296 0 1598621014
pending 2683

This Overpass API instance is running for personal use on a server in my home network (96 threads, 700GB Memory)

However, even after increasing the timeout as above, there appears to be a 24 hour limit being met when trying to calculate the areas during initial setup. See the tail -n of the nohup ... >> rules_loop.out here:

After 23h58m22s: in "recurse", part 0, on line 26. Stack: 0 of 0 4354 of 0 0 of 0
After 23h58m41s: in "recurse", part 0, on line 26. Stack: 0 of 0 4355 of 0 0 of 0
After 23h58m58s: in "recurse", part 0, on line 26. Stack: 0 of 0 4356 of 0 0 of 0
After 23h59m15s: in "recurse", part 0, on line 26. Stack: 0 of 0 4357 of 0 0 of 0
After 23h59m33s: in "recurse", part 0, on line 26. Stack: 0 of 0 4358 of 0 0 of 0
After 23h59m51s: in "recurse", part 0, on line 26. Stack: 0 of 0 4359 of 0 0 of 0
After 24h0m9s: in "recurse", part 0, on line 26. Stack: 0 of 0 4360 of 0 0 of 0
After 24h0m9s: in "recurse", part 0, on line 26. Stack: 0 of 0 4360 of 0 0 of 0

</osm>
runtime error: Query timed out in "recurse" at line 26 after 86409 seconds.
<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="Overpass API 0.7.56.3 eb200aeb">
<note>The data included in this document is from www.openstreetmap.org. The data is made available under ODbL.
</note>
<meta osm_base="2020-07-31T00:00:00Z" areas="2020-07-31T00:00:00Z"/>

Is there a different method to be used for setting timeouts? Or an alternate method to calculate the areas? What is missing here?

Edit: rules_loop.sh is properly calling the --rules flag for osm3s_query too:

#!/usr/bin/env bash

# Copyright 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 Roland Olbricht et al.
#
# This file is part of Overpass_API.
#
# Overpass_API is free software: you can redistribute it and/or modify
# it under the terms of the GNU Affero General Public License as
# published by the Free Software Foundation, either version 3 of the
# License, or (at your option) any later version.
#
# Overpass_API is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU Affero General Public License
# along with Overpass_API. If not, see <https://www.gnu.org/licenses/>.

while [[ true ]]; do
{
  echo "`date '+%F %T'`: update started" >> $EXEC_DIR/db/rules_loop.log
  $EXEC_DIR/bin/osm3s_query --progress --rules </srv/overpass/osm-3s_v0.7.56.3/db/rules/areas.osm3s
  echo "`date '+%F %T'`: update finished" >> $EXEC_DIR/db/rules_loop.log
  sleep 3
}; done

[mmd-osm]

Wow, this is really slow. Try to increase the timeout value in the areas.osm3s script: https://github.com/drolbr/Overpass-API/blob/master/src/rules/areas.osm3s#L2

[jwest75674]

Thank you, I've increased it now and will see how it goes in a day or so!

This is an older server (2013?), multithreaded processes are reasonably quick due to having so many cores, but I suspect that this is running on a single thread, as such, slow makes sense!

[mmd-osm]

Yes, it's all single threaded. Slow IO probably kills your performance as well.

[jwest75674]

Makes sense. Personal / Hobby project, so I am not in a rush anyways. haha. Thanks again for your help. Will pop back in a day or so either close this issue or ask for guidance.

[jwest75674]

Update here, I ended up deleting my db and diff folders, re-cloning, and otherwise resetting this up. As well, I increased ./dispatcher --size by a few orders of magnitude, which appears to help a ton.

Overall, I am a 10 minutes into the areas portion of this, and rules_loop.sh is already showing that this is running significantly faster.

Sep 02 15:49:22 nominatim rules_loop.sh[20256]: After 0h10m22s: in "recurse", part 0, on line 26. Stack: 0 of 0 3070 of 0 0 of 0
Sep 02 15:49:40 nominatim rules_loop.sh[20256]: After 0h10m40s: in "recurse", part 0, on line 26. Stack: 0 of 0 3188 of 0 0 of 0
Sep 02 15:49:55 nominatim rules_loop.sh[20256]: After 0h10m55s: in "recurse", part 0, on line 26. Stack: 0 of 0 3311 of 0 0 of 0
Sep 02 15:50:10 nominatim rules_loop.sh[20256]: After 0h11m10s: in "recurse", part 0, on line 26. Stack: 0 of 0 3417 of 0 0 of 0

I imagine this will be wrapping up well below a 24 hour threshold now, but admit I am not 100% which portion of this effort has things so greatly improved.

Either way, will leave this issue open for another day or two to be safe, but things seem to be on-track to work. :)

Edit: One question: Should the areas dispatcher and rules_loop.sh be set to run at boot, or are those one time steps? It was unclear to me when reading through the installation instructions at the wiki.

[jwest75674]

Yeah, this is waaaaay faster now.

Sep 02 21:52:40 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 1713049598 is contained in an odd number of ways.
Sep 02 21:52:44 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 2604084727 is contained in an odd number of ways.
Sep 02 21:52:52 nominatim rules_loop.sh[20256]: After 6h13m52s: in "recurse", part 0, on line 27. Stack: 0 of 0 628670 of 0 0 of 0
Sep 02 21:53:07 nominatim rules_loop.sh[20256]: After 6h14m7s: in "recurse", part 0, on line 27. Stack: 0 of 0 628890 of 0 0 of 0
Sep 02 21:53:22 nominatim rules_loop.sh[20256]: After 6h14m22s: in "recurse", part 0, on line 26. Stack: 0 of 0 629275 of 0 0 of 0
Sep 02 21:53:37 nominatim rules_loop.sh[20256]: After 6h14m37s: in "recurse", part 0, on line 27. Stack: 0 of 0 629634 of 0 0 of 0
Sep 02 21:53:52 nominatim rules_loop.sh[20256]: After 6h14m52s: in "recurse", part 0, on line 27. Stack: 0 of 0 630076 of 0 0 of 0
Sep 02 21:53:53 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 6128380201 is contained in an odd number of ways.
Sep 02 21:54:07 nominatim rules_loop.sh[20256]: After 6h15m7s: in "recurse", part 0, on line 27. Stack: 0 of 0 630316 of 0 0 of 0
Sep 02 21:54:22 nominatim rules_loop.sh[20256]: After 6h15m22s: in "make-area", part 0, on line 29. Stack: 0 of 0 630644 of 0

Edit: This would have taken literally the better part of two years to get to where I am, at that old rate. I see what you meant about slow. wow.

Sep 03 21:31:16 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 2255178509 is contained in an odd number of ways.
Sep 03 21:31:21 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 353285703 is contained in an odd number of ways.
Sep 03 21:31:21 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 1771990361 is contained in an odd number of ways.
Sep 03 21:31:21 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 112686793 is contained in an odd number of ways.
Sep 03 21:31:24 nominatim rules_loop.sh[20256]: runtime remark: make-area: Node 6621069117 is contained in an odd number of ways.
Sep 03 21:31:25 nominatim rules_loop.sh[20256]: After 29h52m25s: in "make-area", part 0, on line 257. Stack: 0 of 0 2800237 of 0

[jwest75674]

Thank you!