unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Sam Saffron <sam.saffron@gmail.com>
To: Jeremy Evans <jeremyevans0@gmail.com>
Cc: Eric Wong <e@80x24.org>, unicorn-public <unicorn-public@bogomips.org>
Subject: Re: Log URL with murder_lazy_workers
Date: Mon, 15 Jan 2018 14:22:26 +1100	[thread overview]
Message-ID: <CAAtdryP6PFLe+QfZSiOosQ=uLw9ywYOpqq_4csE0EOgNvnTJwA@mail.gmail.com> (raw)
In-Reply-To: <CADGZSScpXo7-PvM=Ki64hhPSzWAsjyT+fWKAZ9-30U69x+54iA@mail.gmail.com>

Hi Jeremy,

Yes we already have statement timeout set, it just does not trigger
under extreme load cause its usually a piling of papercuts and not one
big nasty query, 26 seconds in you issue yet another query and...
boom. I guess we could prepend a custom exec that times out early and
re-sets it per statement.

Thanks for the suggestion of the info file, I will consider adding
something like it.

Sam

On Mon, Jan 15, 2018 at 1:40 PM, Jeremy Evans <jeremyevans0@gmail.com> wrote:
> On Sun, Jan 14, 2018 at 6:18 PM, Sam Saffron <sam.saffron@gmail.com> wrote:
>>
>> It is super likely this could be handled in the app if we had:
>>
>> db_connection.timeout_at Time.now + 29
>>
>> Then the connection could trigger the timeout and kill off the request
>> without needing to tear down the entire process and re-forking.
>>
>> Making this happen is a bit tricky cause it would require some hacking
>> on the pg gem.
>
>
> Sam,
>
> For this particular case, you can SET statement_timeout (29000) on the
> PostgreSQL connection, but note that is a per statement timeout, not a per
> web request timeout.
>
> What I end up doing for important production apps is have the worker log
> request information for each request to an open file descriptor
> (seek(0)/write/truncate), and having the master process use the contents of
> the worker-specific file to report errors in case of worker crashes.
>
> Thanks,
> Jeremy
>

  parent reply	other threads:[~2018-01-15  3:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-14 23:27 Log URL with murder_lazy_workers Sam Saffron
2018-01-15  1:57 ` Eric Wong
2018-01-15  2:18   ` Sam Saffron
     [not found]     ` <CADGZSScpXo7-PvM=Ki64hhPSzWAsjyT+fWKAZ9-30U69x+54iA@mail.gmail.com>
2018-01-15  3:22       ` Sam Saffron [this message]
2018-01-15 15:06 ` Carl Brasic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAtdryP6PFLe+QfZSiOosQ=uLw9ywYOpqq_4csE0EOgNvnTJwA@mail.gmail.com' \
    --to=sam.saffron@gmail.com \
    --cc=e@80x24.org \
    --cc=jeremyevans0@gmail.com \
    --cc=unicorn-public@bogomips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/unicorn.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).