For one particular query, I see the line read_aborted() - It ran for more than
Is there a way to diagnose why the query was aborted? i.e. did it cross some
query time to run threshold setting.
I found purge_setting initialised to 900. But I couldn't figure out how it was
Also, there doesn't seem to be an http response. I don't see anything in the
nginx logs either.
> Is there a way to diagnose why the query was aborted? i.e. did it cross some
> query time to run threshold setting.
A quer is aborted if ot has been killed by something externally. There
are some but rather uncommon cases where this has been triggered by
ulimit. By contrast, it is most likely that the web server has killed
If the request has missed the quota then it leaves a message 'Oversized'
or 'timed out' respectively in the log files.
> I found purge_setting initialised to 900. But I couldn't figure out how it was
> being used.
I have never heard so far the term 'purge_setting'. Is this really from
Overpass or from somewhere in the web server or OS stack?
> Also, there doesn't seem to be an http response. I don't see anything in the
> nginx logs either.
Sounds even more like something external. Oversized and timed out are
designed to return an error message as part of their payload body.
Essentially because once the process has started to write payload, it
cannot rollback and declare an error.
Hello Mr. Olbricht,
Thanks for the insight. I didn't know it was an external process that
could've done this. It's possible it's the oom killer. I thought it was the
purge command sent from some where in overpass.
Sorry for misleading you with purge_setting. I was probably thinking of
the "purge setting". I mean't purge_timeout in core/settings.cc. I couldn't
figure out if this was the cause of the read_aborted - I don't know how this
setting has any influence on overpass.