transaction log: read_aborted()

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

transaction log: read_aborted()

rougeusered
Hello,
For one particular query, I see the line read_aborted() - It ran for more than
15 min.
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
being used.

Also, there doesn't seem to be an http response. I don't see anything in the
nginx logs either.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: transaction log: read_aborted()

Roland Olbricht
Hello,

> 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
something.

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.

Best regards,

Roland
Reply | Threaded
Open this post in threaded view
|

Re: transaction log: read_aborted()

rougeusered
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.

Thank you
Reply | Threaded
Open this post in threaded view
|

Re: transaction log: read_aborted()

rougeusered
In reply to this post by Roland Olbricht
Hello Mr. Olbricht
  Thanks to your hint about the web server. It is the webserver that is
killing the process. I see it in the logs after isolating the query.
Thank you