unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: "Bráulio Bhavamitra" <braulio@eita.org.br>
To: Eric Wong <normalperson@yhbt.net>
Cc: Unicorn <mongrel-unicorn@rubyforge.org>,
	 unicorn-public <unicorn-public@bogomips.org>
Subject: Re: Does unicorn waits after_work to consider a worker ready?
Date: Thu, 1 May 2014 16:00:50 -0300	[thread overview]
Message-ID: <CAJri6_vCZ1t5XSq=mvSDnciWoQTHMeFpiyKF3Q-1z7zQzkJEWg@mail.gmail.com> (raw)
In-Reply-To: <20140501181814.GA14118@dcvr.yhbt.net>

On Thu, May 1, 2014 at 3:18 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Bráulio Bhavamitra <braulio@eita.org.br> wrote:
>> On Wed, Apr 30, 2014 at 10:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> > You do not need to sleep before warmup.
>> Warm up requests are expensive. This sleep based on worker.nr makes
>> warm up happen on worker by worker, not all at once.
>
> The worker might just be processing the expensive request in a
> user-visible state, correct?
>
> Modern Linux (and I expect most OSes people use nowadays) are great at
> dividing CPU-intensive work fairly.  Of course, if there's disk
> intensive load, that's a different case.
Yeah, I see that frequently on top.

But if all workers are warming up at once, say 10 workers, then the
old workers will slow down to serve requests, as CPU will be heavily used
by the warming up workers. That's is the main reason to slow down warm up.

>
>> > The master never pushes requests to a worker.  The key to unicorn is the
>> > workers pull requests directly from the kernel queue.  The master is
>> > never involved with distributing requests to the worker.
>> Nice! So the kernel "sees" that worker is sleeping and should not pass
>> a request to it, I guess.
>
> Almost, but the kernel socket queueing doesn't really see.  It's more
> like the kernel just puts food on the table continuously without caring
> if workers are eating.  Sometimes the table overflows and food gets
> thrown in the trash when the workers are all sleeping or full.
Interesting... So the queue know about sleeping workers, but we have
to prevent that all workers are sleeping at the same time.

>
>> > On a side note, your config is depressingly long and complex :<
>> > Try to make your apps run well without needing unicorn-worker-killer,
>> > at least...
>> That's the ruby fate... Apps inevitably grow memory over time.
>
> Only if you let bugs stay around.
>
> If you find bugs in Ruby or the libs you use, please report and help get
> them fixed.  Ruby 2.1 had some corner cases, true, but we need to help
> fight against bloated apps.
That's the ruby design, as the heap only grows, so with a request that
loads a lot of data the heap will grow big and never shrink.
http://izumi.plan99.net/blog/index.php/2007/10/12/how-the-ruby-heap-is-implemented/

Ruby 2.1 changes that? We will soon migrate to ruby 2.1, but we are
not ready for it yet.

>
> ...and bloated email signatures :P
:P


-- 
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
http://cirandas.net/brauliobo
http://eita.org.br

"Paramapurusha é meu pai e Parama Prakriti é minha mãe. O universo é
meu lar e todos nós somos cidadãos deste cosmo. Este universo é a
imaginação da Mente Macrocósmica, e todas as entidades estão sendo
criadas, preservadas e destruídas nas fases de extroversão e
introversão do fluxo imaginativo cósmico. No âmbito pessoal, quando
uma pessoa imagina algo em sua mente, naquele momento, essa pessoa é a
única proprietária daquilo que ela imagina, e ninguém mais. Quando um
ser humano criado mentalmente caminha por um milharal também
imaginado, a pessoa imaginada não é a propriedade desse milharal, pois
ele pertence ao indivíduo que o está imaginando. Este universo foi
criado na imaginação de Brahma, a Entidade Suprema, por isso a
propriedade deste universo é de Brahma, e não dos microcosmos que
também foram criados pela imaginação de Brahma. Nenhuma propriedade
deste mundo, mutável ou imutável, pertence a um indivíduo em
particular; tudo é o patrimônio comum de todos."
Restante do texto em
http://cirandas.net/brauliobo/blog/a-problematica-de-hoje-em-dia

  reply	other threads:[~2014-05-01 19:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-30 13:54 Does unicorn waits after_work to consider a worker ready? Bráulio Bhavamitra
2014-05-01  1:33 ` Eric Wong
2014-05-01 15:23   ` Bráulio Bhavamitra
2014-05-01 18:18     ` Eric Wong
2014-05-01 19:00       ` Bráulio Bhavamitra [this message]
2014-05-02 23:43         ` Eric Wong
2014-05-04 12:57           ` Bráulio Bhavamitra
2014-05-04 21:24             ` Bráulio Bhavamitra

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='CAJri6_vCZ1t5XSq=mvSDnciWoQTHMeFpiyKF3Q-1z7zQzkJEWg@mail.gmail.com' \
    --to=braulio@eita.org.br \
    --cc=mongrel-unicorn@rubyforge.org \
    --cc=normalperson@yhbt.net \
    --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).