Open tigattack opened 4 days ago
@tigattack I'd suggest to lower the value of BACKGROUND_PROCESSING_CONCURRENCY
env var to something between 10-30. Sidekiq creates an excessive amount of requests to PostgreSQL database + Nominatim can't handle your reverse geocoding request as fast as your instance sends them to it
Thanks for the tip @Freika, though I have the processing concurrency set to 10 already. I actually had intended to increase it from the default but hadn't got round to it yet.
I am experiencing the same issue as tigaatack while importing a large Records.json
file. I have just lowered the processing concurrency to 10 (from 30) and this has seemed to resolve the issue for me, but I have almost 500,000 failed jobs in Sidekiq. I'm assuming this number is related to the failed reverse geocodings, but I may be wrong, is there anyway to retry these failed jobs?
Describe the bug
During the reverse geocoding phase of the import process, I'm seeing a lot of
ActiveRecord::ConnectionTimeoutError
errors from Sidekiq. The large majority of the reverse geocoding jobs appear to succeed without encountering this error, but it still occurs roughly once every few minutes.I'm importing a 1.6GB
Records.json
file from my Google Takeout with approximately 3.6 million geopoints.Version
0.8.0
To Reproduce
I can't guarantee this will reproduce it as I'm not sure exactly what the cause is, but it appears to be consistent for me:
Expected behavior
I would expect this error to not occur.
Screenshots N/A.
Logs
Logs from dawarich_app are not relevant but here is a snippet of an occurence of the error from dawarich_sidekiq:
Additional context
While the following error does not appear to cause the error above, I thought it worth mentioning as it occurs for almost all reverse geocoding jobs: