unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
						download: 
* [ANN] unicorn 0.95.1 - we <3 symlink deployments more
@ 2009-11-21 22:00 Eric Wong
  0 siblings, 0 replies; 6+ results
From: Eric Wong @ 2009-11-21 22:00 UTC (permalink / raw)
  To: mongrel-unicorn, ruby-talk

Unicorn is an HTTP server for Rack applications designed to only serve
fast clients on low-latency, high-bandwidth connections and take
advantage of features in Unix/Unix-like kernels.  Slow clients should
only be served by placing a reverse proxy capable of fully buffering
both the the request and response in between Unicorn and slow clients.

* http://unicorn.bogomips.org/
* mongrel-unicorn@rubyforge.org
* git://git.bogomips.org/unicorn.git

Changes:

Configuration files paths given on the command-line are no
longer expanded.  This should make configuration reloads
possible when a non-absolute path is specified for --config-file
and Unicorn was deployed to a symlink directories (as with
Capistrano).  Since deployments have always been strongly
encouraged to use absolute paths in the config file, this
change does not affect absolute path users.

This is our first gem release using gemcutter.  And we *just*
got it working while I was writing this message :>

Eric Wong (3):
      SIGNALS: HUP + preload_app cannot reload app code
      Do not expand paths given on the shell
      GNUmakefile: prep release process for gemcutter

-- 
Eric Wong

^ permalink raw reply	[relevance 5%]

* Re: feature request - when_ready() hook
      [irrelevant] ` <20091126060519.GC22762@dcvr.yhbt.net>
@ 2009-11-26 19:05   ` Suraj Kurapati
  0 siblings, 0 replies; 6+ results
From: Suraj Kurapati @ 2009-11-26 19:05 UTC (permalink / raw)
  To: unicorn list

On Wed, Nov 25, 2009 at 10:05 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Suraj Kurapati <sunaku@gmail.com> wrote:
>> * before_fork() -- approx. 2 minute downtime
>> * after_fork() -- approx. 2 minute downtime
>> * storing the old-master-killing logic inside a lambda in after_fork()
>> (for the last worker only) and later executing that lambda in Rails'
>> config.after_initialize() hook -- approx. 20 second downtime
>
> I'm looking at those times and can't help but wonder if there's
> something very weird/broken with your setup..  20 seconds is already an
> eternity (even with preload_app=false), but 2 minutes?(!).

Yes, I am using preload_app=false.  These delays mainly come from
establishing DB connections and loading XML datasets into the Rails
app.  Our production DBs are pretty slow to give out new connections.
The startup time is much faster in development, where I use SQLite.

Please note that the reported downtimes are shocking only because they
were *visible* downtimes, where the last worker of the new Unicorn
master killed the old Unicorn master too soon.  IMHO, it doesn't
matter how long it takes for the Rails app to become ready, so long as
the old Unicorn master + workers continue to exist & service requests
until the new Unicorn master + workers take over.

> Are you doing per-process listeners and retrying?  The new ones could be
> fighting for a port held by the old workers...  Other than that...

No, I have one listen() call (on a UNIX socket) at the top level of my
Unicorn configuration file.  Nothing fancy.

> I have many questions, because those times look extremely scary to me
> and I wonder if such a hook would only be masking the symptoms of
> a bigger problem.
>
> What kind of software/hardware stack are you running?
> (please don't say NSLU2 :)

The hardware is some kind of VM running on a VM server farm, running CentOS 4.

The software is Ruby 1.9.1-p243 with Rails 2.3.3, running on Unicorn
0.95.1, behind Nginx, behind M$ IIS.

> How many workers?

Three.

> How heavy is traffic on the site when you're deploying?

About 15 to 20 users.

> How long does it take for a single worker to get ready and start
> serving requests?

Approximately 2 minutes.

> Are you using preload_app?  It should be faster if you do, but there
> really appears to be something else wrong based on those times.

I was for a few weeks, but I stopped because the XML dataset loading
(see above) kept increasing the master's (and the new set of workers')
memory footprint by 1.5x every time Unicorn was restarted via SIGUSR2.

>> As you can see, the more I delayed the execution of that "killing the
>> old master" logic, the closer I got to zero downtime deploys.  In this
>> manner, I request the addition of a when_ready() hook which is
>> executed just after Unicorn prints "worker=# ready!" to its error log
>> inside Unicorn::HttpServer#worker_loop().
>
> At this stage, maybe even implementing something as middleware and
> making it hook into request processing (that way you really know the
> worker is really responding to requests) is the way to go...

Hmm, but that would incur a penalty on each request (check if I've
already killed the old master and do it if necessary).  I'm pretty
confident that killing the old master in the when_ready() hook will be
Good Enough for my setup (at most I expect to see 1-2 second
"down"time).  Let me try this out and I'll tell you the results &
submit a patch.

>> my unicorn setup does not run very close to the memory limit of
>> its host; instead, the amount of free memory is more than double of
>> the current unicorn memory footprint, so I can safely spawn a second
>> set of Unicorn master + workers (via SIGUSR2) without worrying about
>> the SIGTTOU before_fork() strategy shown in the Unicorn configuration
>> example.)
>
> Given your memory availability, I wouldn't even worry about the
> automated killing of the old workers.
>
> Automatically killing old workers means you need a redeploy to roll back
> changes, whereas if you SIGWINCH the old set away, you can HUP the old
> master to bring them back in case the new set is having problems.

Wow this is cool.  Perhaps this strategy could be mentioned in the
documentation?

Thanks for your consideration.
_______________________________________________
mongrel-unicorn mailing list
mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn

^ permalink raw reply	[relevance 3%]

* Re: where to chmod socket file?
      [irrelevant]     ` <cfbcd2f00911141752j13c91f98h6772dff59a473201@mail.gmail.com>
@ 2009-11-30 22:34       ` Suraj Kurapati
  2009-12-01  0:41         ` Eric Wong
  0 siblings, 1 reply; 6+ results
From: Suraj Kurapati @ 2009-11-30 22:34 UTC (permalink / raw)
  To: unicorn list

Eric Wong wrote:
> [PATCH] configurator: listen :umask parameter for UNIX sockets

Hi Eric,

I'm using Unicorn 0.95.1 and I think that the :umask option is
behaving inversely.

For example, if I specify :umask => 0600, the socket file ends up with
s---rwxrwx (same as chmod 0077) permissions.  In contrast, if I
specify :umask => 0177, the socket file ends up with srw------- (same
as chmod 0600) permissions.

Is umask normally specified as the inverse of a desired chmod?

Thanks for your consideration.

^ permalink raw reply	[relevance 4%]

* Re: where to chmod socket file?
  2009-11-30 22:34       ` where to chmod socket file? Suraj Kurapati
@ 2009-12-01  0:41         ` Eric Wong
  0 siblings, 0 replies; 6+ results
From: Eric Wong @ 2009-12-01  0:41 UTC (permalink / raw)
  To: unicorn list

Suraj Kurapati <sunaku@gmail.com> wrote:
> Eric Wong wrote:
> > [PATCH] configurator: listen :umask parameter for UNIX sockets
> 
> Hi Eric,
> 
> I'm using Unicorn 0.95.1 and I think that the :umask option is
> behaving inversely.
> 
> For example, if I specify :umask => 0600, the socket file ends up with
> s---rwxrwx (same as chmod 0077) permissions.  In contrast, if I
> specify :umask => 0177, the socket file ends up with srw------- (same
> as chmod 0600) permissions.
> 
> Is umask normally specified as the inverse of a desired chmod?

Hi Suraj, that's how umask works.  "man 2 umask"

-- 
Eric Wong

^ permalink raw reply	[relevance 0%]

* Expect 100-continue errors
@ 2009-12-09 21:05 Jan Dvorak
  0 siblings, 0 replies; 6+ results
From: Jan Dvorak @ 2009-12-09 21:05 UTC (permalink / raw)
  To: mongrel-unicorn

Hello,

i'm trying to implement handling of http Expect: 100-continue with
unicorn in my rails app, but when i return [100] as a response (which
should force unicorn to return 100 status and rerun my app with the same
connection) i get this error:

Read error: #<ThreadError: stopping only thread
    note: use sleep to stop forever>
/var/lib/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:31:in
`lock'
/var/lib/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/reloader.rb:31:in
`run'
/var/lib/gems/1.8/gems/actionpack-2.3.5/lib/action_controller/dispatcher.rb:108:in
`call'
/var/lib/gems/1.8/gems/rails-2.3.5/lib/rails/rack/static.rb:31:in `call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:46:in `call'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:40:in `each'
/var/lib/gems/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:40:in `call'
/var/lib/gems/1.8/gems/rails-2.3.5/lib/rails/rack/log_tailer.rb:17:in `call'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:576:in `process_client'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:643:in `worker_loop'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:641:in `each'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:641:in `worker_loop'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:534:in
`spawn_missing_workers'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:534:in `fork'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:534:in
`spawn_missing_workers'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:530:in `each'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:530:in
`spawn_missing_workers'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:540:in
`maintain_worker_count'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:215:in `start'
/var/lib/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:28:in `run'
/var/lib/gems/1.8/gems/unicorn-0.95.1/bin/unicorn_rails:207
/var/lib/gems/1.8/bin/unicorn_rails:19:in `load'
/var/lib/gems/1.8/bin/unicorn_rails:19

Any idea about what's wrong ?

Thanks,
Jan
_______________________________________________
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


^ permalink raw reply	[relevance 7%]

* Strange Thread related errors
@ 2010-01-07 16:05 Michael Guterl
  0 siblings, 0 replies; 6+ results
From: Michael Guterl @ 2010-01-07 16:05 UTC (permalink / raw)
  To: unicorn list

Our Rails app has started raising exceptions (caught by hoptoad
thankfully) and I can only imagine they're related to unicorn.  I only
*think* the errors are occurring on the request after we deploy, which
upgrades the Unicorn process.  I say this because the errors are
coming from many different actions, but I haven't been able to
reproduce.

After the most recent batch of errors, I upgraded from 0.95.1 to
0.95.3, but we have not deployed again.

ThreadError: stopping only thread note: use sleep to stop forever

/usr/local/lib/ruby/1.8/monitor.rb:285:in `stop'

/usr/local/lib/ruby/1.8/monitor.rb:285:in `mon_acquire'

/usr/local/lib/ruby/1.8/monitor.rb:214:in `mon_enter'

/usr/local/lib/ruby/1.8/monitor.rb:240:in `synchronize'

/usr/local/lib/ruby/1.8/logger.rb:496:in `write'

/usr/local/lib/ruby/1.8/logger.rb:326:in `add'

/usr/local/lib/ruby/1.8/logger.rb:374:in `info'

/home/deploy/public_html/rm/releases/20100107153636/vendor/plugins/newrelic_rpm/lib/new_relic/agent/agent.rb:46:in
`ensure_worker_thread_started'

/home/deploy/public_html/rm/releases/20100107153636/vendor/plugins/newrelic_rpm/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:248:in
`perform_action'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/base.rb:532:in
`send'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/base.rb:532:in
`process_without_filters'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/filters.rb:606:in
`process'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/base.rb:391:in
`process'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/base.rb:386:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/routing/route_set.rb:437:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:87:in
`dispatch'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:121:in
`_call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:130:in
`build_middleware_stack'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activerecord/lib/active_record/query_cache.rb:29:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/query_cache.rb:34:in
`cache'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activerecord/lib/active_record/query_cache.rb:9:in
`cache'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activerecord/lib/active_record/query_cache.rb:28:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:361:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/string_coercion.rb:25:in
`call'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/head.rb:9:in `call'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/methodoverride.rb:24:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/params_parser.rb:15:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/session/cookie_store.rb:93:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/activesupport/lib/active_support/cache/strategy/local_cache.rb:24:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/failsafe.rb:26:in
`call'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/lock.rb:11:in `call'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/lock.rb:11:in
`synchronize'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/lock.rb:11:in `call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/actionpack/lib/action_controller/dispatcher.rb:106:in
`call'

/home/deploy/public_html/rm/releases/20100107153636/vendor/rails/railties/lib/rails/rack/static.rb:31:in
`call'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:46:in `call'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:40:in `each'

/usr/local/lib/ruby/gems/1.8/gems/rack-1.0.1/lib/rack/urlmap.rb:40:in `call'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:571:in
`process_client'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:643:in
`worker_loop'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:641:in `each'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:641:in
`worker_loop'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:534:in
`spawn_missing_workers'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:534:in `fork'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:534:in
`spawn_missing_workers'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:530:in `each'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:530:in
`spawn_missing_workers'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:540:in
`maintain_worker_count'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:215:in `start'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/lib/unicorn.rb:28:in `run'

/usr/local/lib/ruby/gems/1.8/gems/unicorn-0.95.1/bin/unicorn_rails:207

/usr/local/bin/unicorn_rails:19:in `load'

/usr/local/bin/unicorn_rails:19
_______________________________________________
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


^ permalink raw reply	[relevance 7%]

Results 1-6 of 6 | reverse results
2009-11-21 22:00 [ANN] unicorn 0.95.1 - we <3 symlink deployments more Eric Wong
    [irrelevant] <cfbcd2f00911252050y3f43f950y77123253e1284d90@mail.gmail.com>
    [irrelevant] ` <20091126060519.GC22762@dcvr.yhbt.net>
2009-11-26 19:05   ` feature request - when_ready() hook Suraj Kurapati
    [irrelevant] <cfbcd2f00911121536rd0582b8u961f7f2a8c6e546a@mail.gmail.com>
    [irrelevant] ` <20091113020351.GA5577@dcvr.yhbt.net>
    [irrelevant]   ` <20091115002433.GA29378@dcvr.yhbt.net>
    [irrelevant]     ` <cfbcd2f00911141752j13c91f98h6772dff59a473201@mail.gmail.com>
2009-11-30 22:34       ` where to chmod socket file? Suraj Kurapati
2009-12-01  0:41         ` Eric Wong
2009-12-09 21:05 Expect 100-continue errors Jan Dvorak
2010-01-07 16:05 Strange Thread related errors Michael Guterl


unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help

Archives are clonable:
	git clone --mirror https://bogomips.org/unicorn-public
	git clone --mirror http://ou63pmih66umazou.onion/unicorn-public

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn
	nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git