Re: dropping Ruby 1.8 support for unicorn 5?
- by Eric Wong @ 10/18 - next

On a related note, I hope nobody is still on Ruby 1.9.1 or (shudder)
1.9.0.

I'd like to use require_relative; a 1.9.2+ feature and 1.9.2 is already
EOL these days.  I think there's still many 1.9.3 users out there, so we
need to continue supporting that for a while.

message raw reply parent permalink

Reserved workers not as webservers
- by Bráulio Bhavamitra @ 10/09 - next/prev

Hello all,

I'm quite amazed of how preloading and fork and reduce memory usage.
Making it use even less memory and restarting the app faster, the next
step would be incorporate other daemons (also part of the app, in my
case delayed_job and feed-updater) AS unicorn workers.

This would be very interesting as restarting unicorn would also
restart these daemons.
Another benefit of incorporating daemons into unicorn is sharing pidfile.

For it to work properly I would have to reserve some workers for these
daemons. Today, I would simple do a condition on worker.nr and apply a
specific code to start the daemon. Maybe better would be to have a
different type of worker designed for this.

But something I don't know how to do is to disable http requests to be
forwared to these workers. How could I do it?

Have you ever thought in doing this?

best regards,
bráulio

message raw reply permalink

  Re: Reserved workers not as webservers
  - by Michael Fischer @ 10/09 - next/prev

  On Thu, Oct 9, 2014 at 5:24 AM, Bráulio Bhavamitra <braulio@eita.org.br>
  wrote:
  
  I'm quite amazed of how preloading and fork and reduce memory usage.
  > Making it use even less memory and restarting the app faster, the next
  > step would be incorporate other daemons (also part of the app, in my
  > case delayed_job and feed-updater) AS unicorn workers.
  
  
  As your friendly neighborhood service engineer, my experience is that
  separating the concerns (keeping asynchronous processors separate from your
  synchronouous web services) is worth the additional memory and processor
  cost.  The two usually don't scale at the same rate, and you want to keep
  your failure domains separate as well: you don't want a bug in the async
  processor cause your web server to crash as well.   And let's not even get
  into the programming and maintenance challenges.
  
  There is such as thing as being too cheap. :)
  
  --Michael

  message raw reply parent permalink

    Re: Reserved workers not as webservers
    - by Devin Ben-Hur @ 10/09 - next/prev

    On 10/9/14, 9:45 AM, Michael Fischer wrote:
    > <On Thu, Oct 9, 2014 at 5:24 AM, Bráulio Bhavamitra ...>
    
    Excellent points Michael.  But to Bráulio's original request, it would 
    be lovely to factor out the clean and robust process management parts of 
    unicorn (daemonization, pidfile-mgmt, pre-load, fork, reap, signaling) 
    separate from the HTTP/Rack server.  This would give us a robust 
    supervisor for asynchronous workers that reduce memory footprint with 
    CoW and responds to a well understood set of signals for management.

    message raw reply parent permalink

      Re: Reserved workers not as webservers
      - by Michael Fischer @ 10/09 - next/prev

      On Thu, Oct 9, 2014 at 10:14 AM, Devin Ben-Hur <dbenhur@whitepages.com>
      wrote:
      
      >
      > Excellent points Michael.  But to Bráulio's original request, it would be
      > lovely to factor out the clean and robust process management parts of
      > unicorn (daemonization, pidfile-mgmt, pre-load, fork, reap, signaling)
      > separate from the HTTP/Rack server.  This would give us a robust supervisor
      > for asynchronous workers that reduce memory footprint with CoW and responds
      > to a well understood set of signals for management.
      >
      
      Take a look at resque-pool (https://github.com/nevans/resque-pool) for one
      example of a pre-existing solution.  I'm sure there are others.
      
      --Michael

      message raw reply parent permalink

      Re: Reserved workers not as webservers
      - by Eric Wong @ 10/09 - next/prev

      Devin Ben-Hur <dbenhur@whitepages.com> wrote:
      > Excellent points Michael.  But to Bráulio's original request, it
      > would be lovely to factor out the clean and robust process
      > management parts of unicorn (daemonization, pidfile-mgmt, pre-load,
      > fork, reap, signaling) separate from the HTTP/Rack server.
      
      I think some projects exist nowadays (and were inspired by unicorn).
      I also cannot speak to the quality of them, though.
      
      My take is that stuff ends up being fairly specific to the type of
      app used and putting an abstraction around them makes it harder to learn
      and use than the lower-level primitives Ruby provides.
      
      The ordering of some things (e.g. writing pid file, preload, binding
      sockets, hooks, timeout checks) seems subject to the needs of the
      specific server; and it's easier to figure out the ordering of those
      things when the lower-level parts are right in front of you instead of
      abstracted away in a library.
      
      Having Ruby as an abstraction around C syscalls is great since I don't
      have to worry about things like buffer overruns or error-checking every
      single syscall.  More abstraction than that ends up hiding too many
      important details, making programming and maintenance harder.

      message raw reply parent permalink

        Re: Reserved workers not as webservers
        - by Bráulio Bhavamitra @ 10/09 - next/prev

        Eric, how with a simple monkey patch will allow a worker to not
        connect with the kernel request queue?
        
        On Thu, Oct 9, 2014 at 2:34 PM, Eric Wong <e@80x24.org> wrote:
        > <Devin Ben-Hur <dbenhur@whitepages.com> wrote: >> Excellent ...>

        more... raw reply parent permalink

          Re: Reserved workers not as webservers
          - by Eric Wong @ 10/09 - next/prev

          Bráulio Bhavamitra <braulio@eita.org.br> wrote:
          > Eric, how with a simple monkey patch will allow a worker to not
          > connect with the kernel request queue?
          
          The listen socket is inherited by default.  Closing it works.  You can
          also keep the socket open and avoid calling any accept() wrappers, that
          is like a "pop" operation on the queue:
          
            kgio_tryaccept in unicorn, accept/accept_nonblock/sysaccept in stdlib
          
          Also, please don't top-post (or send giant sigs).  Thanks.

          message raw reply parent permalink

            Re: Reserved workers not as webservers
            - by Bráulio Bhavamitra @ 10/11 - next/prev

            On Thu, Oct 9, 2014 at 3:15 PM, Eric Wong <e@80x24.org> wrote:
            > Bráulio Bhavamitra <braulio@eita.org.br> wrote:
            >> Eric, how with a simple monkey patch will allow a worker to not
            >> connect with the kernel request queue?
            >
            > The listen socket is inherited by default.  Closing it works.  You can
            > also keep the socket open and avoid calling any accept() wrappers, that
            > is like a "pop" operation on the queue:
            >
            >   kgio_tryaccept in unicorn, accept/accept_nonblock/sysaccept in stdlib
            Done. If you have free time, please take a look at
            https://gist.github.com/brauliobo/11298486#file-unicorn-conf-rb-L139
            
            >
            > Also, please don't top-post (or send giant sigs).  Thanks.
            Sorry for that (again)

            message raw reply parent permalink

              Re: Reserved workers not as webservers
              - by Bráulio Bhavamitra @ 10/13 - next/prev

              I'm pretty happy to say this daemons setup is working beautifully on
              three production rails apps (10 workers each). It is really nice to
              have one pid/master process for the entire app, to know unicorn master
              restarts the daemons if they crash (which sometimes happens with
              delayed_job), and to restart the app and daemons all by once (with
              USR2 signal), and fast!
              
              Thanks Eric and other unicorn developers!
              
              cheers,
              bráulio
              
              On Sat, Oct 11, 2014 at 12:35 AM, Bráulio Bhavamitra
              <braulio@eita.org.br> wrote:
              > <On Thu, Oct 9, 2014 at 3:15 PM, Eric Wong <e@80x24.org> wrote: ...>

              message raw reply parent permalink

      Re: Reserved workers not as webservers
      - by Bráulio Bhavamitra @ 10/09 - next/prev

      On Thu, Oct 9, 2014 at 2:14 PM, Devin Ben-Hur <dbenhur@whitepages.com> wrote:
      > <On 10/9/14, 9:45 AM, Michael Fischer wrote: >> >> On Thu, ...>
      
      That would be great! If unicorn's server except HTTP specific code
      could be extracted into a separate gem it would be fantastic :)

      message raw reply parent permalink

    Re: Reserved workers not as webservers
    - by Bráulio Bhavamitra @ 10/09 - next/prev

    Hello Michael,
    
    As being forked process, I never saw a worker problem crashing master
    or other workers.
    
    Also, unicorn takes care to restart workers if they die, and that is
    very useful for daemons to.
    
    I agree with your scaling point, but that could be solved with
    different unicorn configurations.
    
    cheers,
    bráulio
    
    On Thu, Oct 9, 2014 at 1:45 PM, Michael Fischer <mfischer@zendesk.com> wrote:
    > <On Thu, Oct 9, 2014 at 5:24 AM, Bráulio Bhavamitra ...>

    more... raw reply parent permalink

      Re: Reserved workers not as webservers
      - by Michael Fischer @ 10/09 - next/prev

      On Thu, Oct 9, 2014 at 10:43 AM, Bráulio Bhavamitra <braulio@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 leak and in response,
      the kernel's OOM killer decides to kill your webserver children.
      
      --Michael

      message raw reply parent permalink

        Re: Reserved workers not as webservers
        - by Bráulio Bhavamitra @ 10/09 - next/prev

        Oh I see you are talking about the case you have many machines for a
        web app. The ones I admin is one VPS for all services. :)
        
        On Thu, Oct 9, 2014 at 2:59 PM, Michael Fischer <mfischer@zendesk.com> wrote:
        > On Thu, Oct 9, 2014 at 10:43 AM, Bráulio Bhavamitra <braulio@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 leak and in response,
        > the kernel's OOM killer decides to kill your webserver children.
        >
        > --Michael

        more... raw reply parent permalink

Unicorn not working in GitLab 7.3
- by Onno van der Straaten @ 10/06 - next/prev

Hi,
I am using unicorn in GitLab 7.3. I found that unicorn will not serve
javascript files. There is no response. Other files such as css files work
fine.

I have created an issue at the GitLab site as unicorn is part of his
product. For your information
https://github.com/gitlabhq/gitlabhq/issues/7973
Best Regards,
Onno
-------------------------------- part #2 --------------------------------
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

message raw reply permalink

  Re: Unicorn not working in GitLab 7.3
  - by Onno van der Straaten @ 10/06 - next/prev

  This is unicorn 4.6.3 btw. On the other machine it is the same
  version 4.6.3. So maybe this issue is releated to using unicorn on CentOS.
  
  On Mon, Oct 6, 2014 at 5:04 PM, Onno van der Straaten <
  onno.van.der.straaten@gmail.com> wrote:
  
  > Hi,
  > I am using unicorn in GitLab 7.3. I found that unicorn will not serve
  > javascript files. There is no response. Other files such as css files work
  > fine.
  >
  > I have created an issue at the GitLab site as unicorn is part of his
  > product. For your information
  > https://github.com/gitlabhq/gitlabhq/issues/7973
  > Best Regards,
  > Onno
  >
  >
  -------------------------------- part #2 --------------------------------
  Content-Type: text/html; charset=UTF-8
  Content-Transfer-Encoding: quoted-printable

  message raw reply parent permalink

    Re: Unicorn not working in GitLab 7.3
    - by Eric Wong @ 10/07 - next/prev

    Onno van der Straaten <onno.van.der.straaten@gmail.com> wrote:
    > On Mon, Oct 6, 2014 at 5:04 PM, Onno van der Straaten wrote:
    
    (Top-posting corrected.  Please do not send HTML email as it ends up
     marked as spam.  You would've gotten a response much earlier if you
     sent as plain text)
    
    > > Hi,
    > > I am using unicorn in GitLab 7.3. I found that unicorn will not serve
    > > javascript files. There is no response. Other files such as css files work
    > > fine.
    > >
    > > I have created an issue at the GitLab site as unicorn is part of his
    > > product. For your information
    > > https://github.com/gitlabhq/gitlabhq/issues/7973
    
    This doesn't seems to be a configuration error or a bug in GitLab.
    unicorn itself does not serve files, but just returns what Rack tells
    it to do.
    
    But since you're getting 60s timeouts, something seems seriously wrong
    with that config; but at least you're on Linux so maybe strace can
    help...
    
    > This is unicorn 4.6.3 btw. On the other machine it is the same
    > version 4.6.3. So maybe this issue is releated to using unicorn on CentOS.
    
    Can you try:
    
    1) configuring only single worker process
    2) strace that worker process (strace -p $PID_OF_WORKER)
    3) send only one request for a JS file to see what's happening?
    
    
    In any case, if this GitLab instance is meant for any slow/unreliable
    client connections outside your LAN, nginx should be serving static
    files.  unicorn is grossly inefficient for that (as explained on our
    website):
    
      http://unicorn.bogomips.org/PHILOSOPHY.html

    message raw reply parent permalink

[ANN] email submission port (587) enabled
- by Eric Wong @ 10/04 - next/prev

For those of you unfortunate enough to be stuck behind firewalls
or rely on crap webmail interfaces, you can pass the:

   --smtp-server-port=587 --smtp-server=bogomips.org

options to "git send-email" when sending patches/plain-text mail
to unicorn-public@bogomips.org

You'll still need a valid From: address to receive replies and
participate in the discussion if you're not subscribed to the
mailing list.

Note: "git send-email" can send regular plain-text emails with
valid Subject: and From: headers.  If you're not familiar with
email message headers, they're nearly identical to HTTP, and
you can use "git format-patch"-generated patches as a guide.

Caveats:

- This will expose your client IP address to the world
  (but many existing mail setups do that anyways)

- This will not work for Cc-ing others in replies directly,
  but works for all @bogomips.org email addresses,
  so you may want to add "--suppress-cc=all" or similar.

Patchbomb away! :D

ref: http://www.ietf.org/rfc/rfc4409.txt
  https://www.kernel.org/pub/software/scm/git/docs/git-send-email.html

message raw reply permalink

  Re: [ANN] email submission port (587) enabled
  - by Eric Wong @ 10/05 - next/prev

  Eric Wong <e@80x24.org> wrote:
  > - This will expose your client IP address to the world
  >   (but many existing mail setups do that anyways)
  
  You may use tor to get around this:
  
  	tsocks git send-email ...

  message raw reply parent permalink

Re: Master hooks needed
- by Bráulio Bhavamitra @ 10/04 - next/prev

The problem is actually worser, and the worker.nr == 0 can't be used.
I had to do something like this:

master_run = true

before_fork do |server, worker|
  if master_run
     #warm up server...

     #kill old pid...

     #disconnect active record

     master_run = false
  end

  # other stuff for each worker
end

In the last example, using worker.nr == 0 would make the server crash
in case the worker 0 was killed/restarted.

Also the AR's disconnect and *many other stuff* people put on
before_fork should only be run once the master was preloaded, not for
every worker.

So I still think at least a hook like master_preloaded(server) is necessary.

cheers,
bráulio

On Fri, Oct 3, 2014 at 9:22 AM, Eric Wong <e@80x24.org> wrote:
> <Bráulio Bhavamitra <braulio@eita.org.br> wrote: >> ...>

message raw reply parent permalink

  Re: Master hooks needed
  - by Eric Wong @ 10/04 - next/prev

  Bráulio Bhavamitra <braulio@eita.org.br> wrote:
  > <The problem is actually worser, and the worker.nr == 0 can't be ...>
  
  AR disconnect! is idempotent and has been since unicorn existed.
  I suspect most other things people run in before_fork are already
  idempotent, too.
  
  > So I still think at least a hook like master_preloaded(server) is necessary.
  
  Using the local 'master_run' variable in your before_fork already
  accomplishes everything you needed, right?
  
  I try to keep unicorn as lean as possible and not bloat it with
  redundant features.  The current hooks already fulfill the minimal
  requirements for supporting apps which do not behave properly under
  preload_app=true, so I am not convinced why a new hook is necessary.

  message raw reply parent permalink

    Re: Master hooks needed
    - by Bráulio Bhavamitra @ 10/04 - next/prev

    I think the hook is needed because I took too much time to figure out
    the problem and much more time to figure out the solution (this
    master_run variable). Also, I don't think this master_run solution is
    elegant.
    
    cheers,
    bráulio
    
    On Fri, Oct 3, 2014 at 10:22 PM, Eric Wong <e@80x24.org> wrote:
    > <Bráulio Bhavamitra <braulio@eita.org.br> wrote: >> The ...>

    message raw reply parent permalink

      Re: Master hooks needed
      - by Eric Wong @ 10/04 - next/prev

      Bráulio Bhavamitra <braulio@eita.org.br> wrote:
      > I think the hook is needed because I took too much time to figure out
      > the problem and much more time to figure out the solution (this
      > master_run variable). Also, I don't think this master_run solution is
      > elegant.
      
      A guard variable is fairly common practice for initialization.
      It's not always nice, but I do not consider the existing hooks
      to be elegant, either; they're only unfortunately necessary.
      
      I consider having redundant features to be even worse.
      
      How about the following documentation change instead?
      
      --- a/examples/unicorn.conf.rb
      +++ b/examples/unicorn.conf.rb
      @@ -54,12 +54,23 @@ GC.respond_to?(:copy_on_write_friendly=) and
       # fast LAN.
       check_client_connection false
       
      +# local variable to guard against running a hook multiple times
      +run_once = true
      +
       before_fork do |server, worker|
         # the following is highly recomended for Rails + "preload_app true"
         # as there's no need for the master process to hold a connection
         defined?(ActiveRecord::Base) and
           ActiveRecord::Base.connection.disconnect!
       
      +  # Occasionally, it may be necessary to run non-idempotent code in the
      +  # master before forking.  Keep in mind the above disconnect! example
      +  # is idempotent and does not need a guard.
      +  if run_once
      +    # do_something_once_here ...
      +    run_once = false # prevent from firing again
      +  end
      +
         # The following is only recommended for memory/DB-constrained
         # installations.  It is not needed if your system can house
         # twice as many worker_processes as you have configured.

      message raw reply parent permalink

        Re: Master hooks needed
        - by Bráulio Bhavamitra @ 10/04 - next/prev

        Documentation is an excelent solution :)
        
        On Fri, Oct 3, 2014 at 10:57 PM, Eric Wong <e@80x24.org> wrote:
        > <Bráulio Bhavamitra <braulio@eita.org.br> wrote: >> I ...>

        more... raw reply parent permalink

          Re: Master hooks needed
          - by Eric Wong @ 10/04 - next/prev

          Bráulio Bhavamitra <braulio@eita.org.br> wrote:
          > Documentation is an excelent solution :)
          
          OK, pushed to the website[1] and unicorn.git as
          commit 3318b070c6513a3baa7ce7ac26f4835f46ccff1f
          
              examples: add run_once to before_fork hook example
          
              There may be code in a before_fork hook which should run only once,
              document an example using a guard variable since it may not be
              immediately obvious to all users.
          
              Inspired-by: Bráulio Bhavamitra <braulio@eita.org.br>
          
          http://bogomips.org/unicorn-public/m/20141004015707.GA1951@dcvr.yhbt.net.html
          
          [1] http://unicorn.bogomips.org/examples/

          message raw reply parent permalink


page: next      atom permalink
- unicorn Rack HTTP server user/dev discussion
A public-inbox, anybody may post in plain-text (not HTML):
unicorn-public@bogomips.org
git URL for ssoma: git://bogomips.org/unicorn-public.git
homepage: http://unicorn.bogomips.org/
subscription optional: unicorn-public+subscribe@bogomips.org