kzk/unicorn-worker-killer

existing connections are dropped with a connection error

Closed this issue · 2 comments

Hi,

I've been testing this plugin under load and notice an issue when a restart is detected.

When a worker restarts, the connections that are attached to the original worker thread are not closed first -- they seem to be held in queue and then cause a timeout error.

Is it possible to stop the unicorn worker from responding to further requests and restart the worker once the existing requests are complete?

Should the worker be killed more softly or slowly? (Perhaps the requests I've made take longer than 10 seconds under load - and are killed instead of quitting). I noticed a configuration but I'm not sure where to set the configuration for these. Do you have an example or suggestion for configuration?

W, [2014-10-07T23:04:04.174562 #14966]  WARN -- : #<Unicorn::HttpServer:0x000000015f6800>: worker (pid: 14966) exceeds max number of requests (limit: 598)
W, [2014-10-07T23:04:04.174735 #14966]  WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 14966) alive: 4635 sec (trial 1)
W, [2014-10-07T23:04:04.362864 #14966]  WARN -- : #<Unicorn::HttpServer:0x000000015f6800>: worker (pid: 14966) exceeds max number of requests (limit: 598)
W, [2014-10-07T23:04:04.363014 #14966]  WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 14966) alive: 4635 sec (trial 2)
E, [2014-10-07T23:04:04.639462 #14939] ERROR -- : reaped #<Process::Status: pid 14966 exit 1> worker=0
I, [2014-10-07T23:04:04.752333 #25218]  INFO -- : worker=0 ready

==> shared/log/unicorn.stderr.log <==
source=rack-timeout id=8945a635e802409614dc020704d47ee2 timeout=20000ms duration=20000ms state=timed_out at=error

==> shared/log/staging.log <==
Rack::Timeout::RequestTimeoutError (Request ran for longer than 20 seconds.):
  app/controllers/sdk_controller.rb:30:in `load_info'
  app/controllers/connect_controller.rb:26:in `connect'

edit:
my config.ru
...
use Unicorn::WorkerKiller::MaxRequests, 500, 600, false
use Unicorn::WorkerKiller::Oom, (320_(1024__2)), (352_(1024**2)), 16, true
...

Hi @markslemko this problem is resolved?

I had to use a different gem.