On Fri, Nov 13, 2015 at 8:51 AM, Jeff Utter wrote:
> I was wondering if anyone can offer any advice in handling stats
> collections between worker processes in forking servers (like unicorn).
> Specifically, I am attempting to work on a solution for the Prometheus ruby
On Tue, Mar 24, 2015 at 11:55 PM, Eric Wong e...@80x24.org wrote:
Actually, are you getting 502 errors returned from nginx in this case?
That would not be harmless. I suggest ensuring rack.input is
fully-drained if that is the case (perhaps using PrereadInput).
No, they're all 200 responses
We have an nginx 1.6.2 proxy in front of a Unicorn 4.8.3 server that
is frequently reporting the following error:
2015/03/24 01:46:01 [error] 11217#0: *872231 readv() failed (104:
Connection reset by peer) while reading upstream
The interesting things are:
1) The upstream is a Unix domain
On Tue, Mar 24, 2015 at 11:23 PM, Eric Wong e...@80x24.org wrote:
So there might be data sitting on the socket if your application
processing returns a response before it parsed the POST request.
When this occurs, the nginx access logs show an HTTP 200 (OK) response
with a 0 byte response
If the response times are falling a minute or so after the reload, I'd
chalk it up to a cold CPU cache. You will probably want to stagger your
reloads across backends to minimize the impact.
--Michael
On Tue, Mar 3, 2015 at 2:24 PM, Sarkis Varozian svaroz...@gmail.com wrote:
We have a rails
On Thu, Oct 9, 2014 at 10:43 AM, BrĂ¡ulio Bhavamitra brau...@eita.org.br
wrote:
As being forked process, I never saw a worker problem crashing master
or other workers.
Process isolation is one thing, but that's not the same thing as system
isolation. Imagine your worker process has a memory
On Mon, Aug 4, 2014 at 12:45 PM, Eric Wong e...@80x24.org wrote:
[1] Perhaps persistent connections will be an option in the future
if the support/documentation overhead is worth it, as nginx
supports persistent connections to backends nowadays.
I don't believe the added complexity is