From: Eric Wong <normalperson@yhbt.net>
To: unicorn list <mongrel-unicorn@rubyforge.org>
Subject: Re: A barrage of unexplained timeouts
Date: Tue, 20 Aug 2013 18:49:02 +0000 [thread overview]
Message-ID: <20130820184902.GA31845@dcvr.yhbt.net> (raw)
In-Reply-To: <1377022272.215912135@apps.rackspace.com>
nick@auger.net wrote:
> "Eric Wong" <normalperson@yhbt.net> said:
> >
> > Do you have any other requests in your logs which could be taking
> > a long time and hogging workers, but not high enough to trigger the
> > unicorn kill timeout.
> I don't *think* so. Most requests finish <300ms. We do have some
> more intensive code-paths, but they're administrative and called much
> less frequently. Most of these pages complete in <3seconds.
>
> For requests that made it to rails logging, the LAST processed request
> before the worker timed-out all completed very quickly (and no real
> pattern in terms of which page may be triggering it.)
This is really strange. This was only really bad for a 7s period?
Has it happened again? Anything else going on with the system at that
time? Swapping, particularly...
And if you're inside a VM, maybe your neighbors were hogging things.
Large PUT/POST requests which require filesystem I/O are particularly
sensitive to this.
> > Is this with Unix or TCP sockets? If it's over a LAN, maybe there's
> > still a bad switch/port/cable somewhere (that happens often to me).
>
> TCP sockets, with nginx and unicorn running on the same box.
OK, that probably rules out a bunch of problems.
Just to be thorough, anything interesting in dmesg or syslogs?
> > With Unix sockets, I don't recall encountering recent problems under
> > Linux. Which OS are you running?
>
> Stock RHEL 5, kernel 2.6.18.
RHEL 5.0 or 5.x? I can't remember /that/ far back to 5.0 (I don't think
I even tried it until 5.2), but don't recall anything being obviously
broken in those...
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
next prev parent reply other threads:[~2013-08-20 18:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-20 14:47 A barrage of unexplained timeouts nick
2013-08-20 16:37 ` Eric Wong
2013-08-20 17:27 ` nick
2013-08-20 17:40 ` Eric Wong
2013-08-20 18:11 ` nick
2013-08-20 18:49 ` Eric Wong [this message]
2013-08-20 20:03 ` nick
2013-08-20 20:42 ` Eric Wong
2013-08-20 21:19 ` nick
2013-08-20 21:32 ` Eric Wong
2013-08-21 13:33 ` nick
2013-08-22 2:32 ` Jimmy Soho
2013-08-22 4:09 ` Eric Wong
2013-08-22 13:10 ` nick
2013-08-22 17:05 ` Eric Wong
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=20130820184902.GA31845@dcvr.yhbt.net \
--to=normalperson@yhbt.net \
--cc=mongrel-unicorn@rubyforge.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).