From normalperson at yhbt.net  Sat Oct  1 00:06:07 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 1 Oct 2011 04:06:07 +0000
Subject: large uploads
In-Reply-To: <CAOf2Z5v6JfxkXWd3YPBpkgT=RMRn+a-RAWKYRrd4u6rfdt+QiA@mail.gmail.com>
References: <CAOf2Z5t0pPf8-9mvnn8T=ep-uiUed-nkvoBdKk+yajqCXDFw=w@mail.gmail.com>
	<20110929184711.GA21222@dcvr.yhbt.net>
	<CAOf2Z5vd3WJJ1iNhGc4wQYcFbC2xWYVsOdrO+gH3aKMt8DGSow@mail.gmail.com>
	<20110929205453.GA15148@dcvr.yhbt.net>
	<CAOf2Z5v6JfxkXWd3YPBpkgT=RMRn+a-RAWKYRrd4u6rfdt+QiA@mail.gmail.com>
Message-ID: <20111001040607.GB22604@dcvr.yhbt.net>

John Joseph Bachir <j at jjb.cc> wrote:
> So buffering the entire request and then sending it to the backend is
> the default behavior of HttpUpstreamModule? That's fascinating. It
> almost seems like that's a bad design choice, because it inhibits the
> possibility of parallel work being done as the request comes in (like,
> it's the opposite of how unix pipes work).

Yes, exactly.  It's a design trade-off; if a client is uploading slowly
(whether intentionally or maliciously) the process-per-client model of
Unicorn is /extremely/ inefficient and will easily be shut down
by slow clients.

If you want to be able to process uploads in a Rack application while
the client is uploading, you'd have to ensure your app is thread-safe
and use Rainbows! + ThreadSpawn/ThreadPool.

From hotchpotch at gmail.com  Tue Oct  4 03:10:38 2011
From: hotchpotch at gmail.com (secondlife)
Date: Tue, 4 Oct 2011 16:10:38 +0900
Subject: Peformance up - using OobGC & GC.disable
Message-ID: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>

Hi,
I'm working at Cookpad Inc.

- http://cookpad.com/

Cookpad is very famous cooking recipe service in Japan,
and largest rails application in Japan.

I applied GC.disable after fork, and a few changed Unicorn::OobGC.

# unicorn.conf.rb
 after_fork do |server, worker|
  GC.disable if RAILS_ENV == 'production'

# OobGC code
 def process_client(client)
  super(client) # Unicorn::HttpServer#process_client
  if OOBGC_PATH =~ OOBGC_ENV[PATH_INFO] && ((@@nr -= 1) <= 0)
    @@nr = OOBGC_INTERVAL
    OOBGC_ENV.clear
    disabled = GC.enable
    GC.start
    GC.disable if disabled
  end
 end

after applied,
application response time 130% fast!
and CPU usage to half!

- http://bit.ly/rhnVlg (response time)
- http://bit.ly/pgMN06 (CPU usage)

This is OobGC patch, apply please.
- http://bit.ly/roVLtZ (patch)

Also, my rails application have memory leaks ;(
I wrote process killing code because GC.disable create more memory leak.
- https://gist.github.com/1258681

------------------------------------------
Yuichi Tateno
https://github.com/hotchpotch

From cliftonk at gmail.com  Tue Oct  4 07:18:08 2011
From: cliftonk at gmail.com (cliftonk at gmail.com)
Date: Tue, 4 Oct 2011 06:18:08 -0500
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
Message-ID: <399D3A45-C912-48D1-91C7-06F319FC7A23@gmail.com>

That looks promising. I'm curious what our app's memory would climb to (at worst).

Clifton

From normalperson at yhbt.net  Tue Oct  4 18:53:05 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 4 Oct 2011 22:53:05 +0000
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
Message-ID: <20111004225305.GA5373@dcvr.yhbt.net>

secondlife <hotchpotch at gmail.com> wrote:
> after applied,
> application response time 130% fast!
> and CPU usage to half!
> 
> - http://bit.ly/rhnVlg (response time)
> - http://bit.ly/pgMN06 (CPU usage)

Thanks for the feedback!  I wonder if 1.9.3 with lazy sweep GC can
provide similar improvements (without needing OobGC or GC.disable,
even).

> This is OobGC patch, apply please.
> - http://bit.ly/roVLtZ (patch)

Thanks! Applied as c7ba76a21c5d00fb5c173cd6aa847442bbc652cb
with the following commit message:

From: Yuichi Tateno <hotchpotch at gmail.com>
Date: Mon, 3 Oct 2011 16:51:19 +0900
Subject: [PATCH] OobGC: force GC.start

[ew: we need to explicitly enable GC if it is disabled
 and respect applications that disable GC]

Acked-by: Eric Wong <normalperson at yhbt.net>

> I wrote process killing code because GC.disable create more memory leak.
> - https://gist.github.com/1258681

I think that could be done entirely as Unicorn-specific Rack middleware
and not hook into Unicorn internal methods like process_client.  Also,
the pid checks are unnecessary since that code never runs in the master.

From hotchpotch at gmail.com  Thu Oct  6 02:22:48 2011
From: hotchpotch at gmail.com (secondlife)
Date: Thu, 6 Oct 2011 15:22:48 +0900
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <20111004225305.GA5373@dcvr.yhbt.net>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
	<20111004225305.GA5373@dcvr.yhbt.net>
Message-ID: <CAGh4DjmVsCMJd2GKDo2evgsn2-TD4O6xiPgxtphc6a7fucR1UQ@mail.gmail.com>

> Thanks! Applied as c7ba76a21c5d00fb5c173cd6aa847442bbc652cb> with the following commit message:
Thank you for applied!

> I think that could be done entirely as Unicorn-specific Rack middleware
> and not hook into Unicorn internal methods like process_client. ?Also,
> the pid checks are unnecessary since that code never runs in the master.

Thank you for advice. I rewrite my code.
- https://gist.github.com/1258681

------------------------------------------
Yuichi Tateno
https://github.com/hotchpotch

From andoriyu at gmail.com  Thu Oct  6 20:34:14 2011
From: andoriyu at gmail.com (Andrey Cherkashin)
Date: Thu, 6 Oct 2011 17:34:14 -0700
Subject: Unicorn failed to handle signals
Message-ID: <B691CEA3-5940-4B46-9F16-68156E843CFE@gmail.com>

I have a problem with unicorn and signals.
FreeBSD freebsd 9.0-BETA3 FreeBSD 9.0-BETA3 #0 r225816+a1b6562: Thu Sep 29 06:46:06 PDT 2011     root at freebsd:/sys/i386/compile/XEN  i386
ruby 1.9.2p290 (2011-07-09 revision 32553) [i386-freebsd9.0]
unicorn (4.1.1)

Every time when I trying to send a signal (HUP, TERM, etc) I get this: Illegal instruction: 4 (core dumped)
I have no idea how to deal with core dump, so here it is: http://www.misprint.org.ru/ruby.core


From andoriyu at gmail.com  Thu Oct  6 20:46:34 2011
From: andoriyu at gmail.com (Andrey Cherkashin)
Date: Thu, 6 Oct 2011 17:46:34 -0700
Subject: Unicorn failed to handle signals
Message-ID: <026125BB-F059-4A07-8869-C298EC74FB8C@gmail.com>

I have a problem with unicorn and signals.
FreeBSD freebsd 9.0-BETA3 FreeBSD 9.0-BETA3 #0 r225816+a1b6562: Thu Sep 29 06:46:06 PDT 2011     root at freebsd:/sys/i386/compile/XEN  i386
ruby 1.9.2p290 (2011-07-09 revision 32553) [i386-freebsd9.0]
unicorn (4.1.1)

Every time when I trying to send a signal (HUP, TERM, etc) I get this: Illegal instruction: 4 (core dumped)
I have no idea how to deal with core dump, so here it is: http://www.misprint.org.ru/ruby.core


From andoriyu at gmail.com  Fri Oct  7 00:44:00 2011
From: andoriyu at gmail.com (Andrey Cherkashin)
Date: Thu, 6 Oct 2011 21:44:00 -0700
Subject: Unicorn failed to handle signals
Message-ID: <EAC7D710-D4C0-4E88-96B3-3EE4C7EF1891@gmail.com>

I have a problem with unicorn and signals.
FreeBSD freebsd 9.0-BETA3 FreeBSD 9.0-BETA3 #0 r225816+a1b6562: Thu Sep 29 06:46:06 PDT 2011     root at freebsd:/sys/i386/compile/XEN  i386
ruby 1.9.2p290 (2011-07-09 revision 32553) [i386-freebsd9.0]
unicorn (4.1.1)

Every time when I trying to send a signal (HUP, TERM, etc) I get this: Illegal instruction: 4 (core dumped)
I have no idea how to deal with core dump, so here it is: http://www.misprint.org.ru/ruby.core


From normalperson at yhbt.net  Fri Oct  7 02:35:47 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Thu, 6 Oct 2011 23:35:47 -0700
Subject: Unicorn failed to handle signals
In-Reply-To: <EAC7D710-D4C0-4E88-96B3-3EE4C7EF1891@gmail.com>
References: <EAC7D710-D4C0-4E88-96B3-3EE4C7EF1891@gmail.com>
Message-ID: <20111007063547.GB9790@dcvr.yhbt.net>

(please don't send the same message twice in a short time period)

Andrey Cherkashin <andoriyu at gmail.com> wrote:
> I have a problem with unicorn and signals.
> FreeBSD freebsd 9.0-BETA3 FreeBSD 9.0-BETA3 #0 r225816+a1b6562: Thu Sep 29 06:46:06 PDT 2011     root at freebsd:/sys/i386/compile/XEN  i386
> ruby 1.9.2p290 (2011-07-09 revision 32553) [i386-freebsd9.0]
> unicorn (4.1.1)

> Every time when I trying to send a signal (HUP, TERM, etc) I get this:
> Illegal instruction: 4 (core dumped) I have no idea how to deal with
> core dump, so here it is: http://www.misprint.org.ru/ruby.core

You can run gdb on it:

$ gdb /path/to/ruby /path/to/core

Then type "bt" to get a backtrace and you can learn other commands.

I suspect this is a bug somewhere in FreeBSD 9.0 BETA3 itself, and
not Unicorn or Ruby.

Can you test some simple scripts using trap?

Something along the lines of:
---------------------- 8< ---------------------
trap(:HUP) do
  puts "HUP received"
end
puts "#$$ ready to receive SIGHUP"
sleep
------------------------------------------------

Thanks.

From phc at zestcash.com  Fri Oct  7 23:20:58 2011
From: phc at zestcash.com (Pai-Hung Chen)
Date: Fri, 7 Oct 2011 20:20:58 -0700
Subject: How to automate the restarting of Unicorn?
Message-ID: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>

Hi,

I have a question about automating the restarting of Unicorn with the
following steps, and much appreciate your help.

Assumption: (i) "pid" is set to unicorn.pid in the config file; (ii) a
Unicorn process is already running.

(1) kill -USR2 `cat unicorn.pid` (via Capistrano deployment task for example)
(2) Inside the "before_exec" hook in the config file, do: kill -QUIT
`cat unicorn.pid.oldbin`

My question is: By the time the "before_exec" hook is executed, is it
guaranteed that unicorn.pid.oldbin ahas lready created (otherwise we
have a racing condition here)? Or is there a better way to achieve
what I want?

Please Cc me as I am not on the mailing list.

Please also let me know if there is a better place to ask this question.

Thanks,
Pai-Hung

From jimneath at gmail.com  Sun Oct  9 04:39:42 2011
From: jimneath at gmail.com (Jim Neath)
Date: Sun, 9 Oct 2011 09:39:42 +0100
Subject: No subject
Message-ID: <FE8D1D8E-93FE-4130-A955-689EF5936FC2@gmail.com>


From ajsharp at gmail.com  Sun Oct  9 19:31:42 2011
From: ajsharp at gmail.com (Alex Sharp)
Date: Sun, 9 Oct 2011 16:31:42 -0700
Subject: How to automate the restarting of Unicorn?
In-Reply-To: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>
References: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>
Message-ID: <D0C8FD0B85DE4305A1EC0EE8B872A1A7@gmail.com>

On Friday, October 7, 2011 at 8:20 PM, Pai-Hung Chen wrote:
> My question is: By the time the "before_exec" hook is executed, is it
> guaranteed that unicorn.pid.oldbin ahas lready created (otherwise we
> have a racing condition here)? Or is there a better way to achieve
> what I want?
I'm not 100% positive, but about 98% -- yes, you can count on the fact that the *.oldbin file will exist on disk before the before_exec block is executed. Eric can confirm this, but I've never had a problem with it... 
> 
> Please Cc me as I am not on the mailing list.
> 
> Please also let me know if there is a better place to ask this question.
You're in the right place -- this is a pretty active mailing list :)

-- 
Alex Sharp

github.com/ajsharp
twitter.com/ajsharp
alexjsharp.com


From dbenhur at whitepages.com  Mon Oct 10 02:04:13 2011
From: dbenhur at whitepages.com (Devin Ben-Hur)
Date: Sun, 9 Oct 2011 23:04:13 -0700
Subject: How to automate the restarting of Unicorn?
In-Reply-To: <D0C8FD0B85DE4305A1EC0EE8B872A1A7@gmail.com>
References: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>
	<D0C8FD0B85DE4305A1EC0EE8B872A1A7@gmail.com>
Message-ID: <4E928ADD.8040900@whitepages.com>

On 10/09/2011 04:31 PM, Alex Sharp wrote:
> On Friday, October 7, 2011 at 8:20 PM, Pai-Hung Chen wrote:
>> My question is: By the time the "before_exec" hook is executed, is it
>> guaranteed that unicorn.pid.oldbin ahas lready created (otherwise we
>> have a racing condition here)? Or is there a better way to achieve
>> what I want?
> I'm not 100% positive, but about 98% -- yes, you can count on the fact that the *.oldbin file will exist on disk before the before_exec block is executed. Eric can confirm this, but I've never had a problem with it...

No need to rely on authority, just read the source: 
https://github.com/defunkt/unicorn/blob/master/lib/unicorn/http_server.rb

Unicorn::HttpServer#pid=(path) setter writes the pid file (lines 179-206).

before_exec is called on line 439 within a fork block in 
Unicorn::HttpServer#reexec (this is the only call to before_exec in the 
code)

prior to that, self.pid= is called passing oldpid whose value is 
"#{pid}.oldbin" (lines 398-401).

[ line numbers may change if you're not looking at commit c7ba76a21c ]

From ononoma at gmail.com  Mon Oct 10 13:05:15 2011
From: ononoma at gmail.com (Tatsuya Ono)
Date: Mon, 10 Oct 2011 18:05:15 +0100
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <CAGh4DjmVsCMJd2GKDo2evgsn2-TD4O6xiPgxtphc6a7fucR1UQ@mail.gmail.com>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
	<20111004225305.GA5373@dcvr.yhbt.net>
	<CAGh4DjmVsCMJd2GKDo2evgsn2-TD4O6xiPgxtphc6a7fucR1UQ@mail.gmail.com>
Message-ID: <CAHBuKRjBedCTDi1yPC4J3+tmzpxLFCkFrm-gyDrTPTF7BOkFHQ@mail.gmail.com>

This solution is awesome. I applied the patch on our staging server
and I've confirmed a significant performance improve. Some
pages(especially complicated ones) responds like 4 times faster than
before.

However it seems that we hit a same issue Yuichi had.?When we had an
access on particular page, I can see memory size of worker increases
5-10MB...

> Also, my rails application have memory leaks ;(
> I wrote process killing code because GC.disable create more memory leak.
> - https://gist.github.com/1258681

Beside I want to avoid to use this solution if possible...

I don't actually understand is why GC.disable solution could introduce
more memory leak. If I simplify the problem, the code is something
like bellow:

---------------
GC.disable
(do something)
GC.enable
GC.start
---------------

When the code block finishes, I expect that memory size should be
(almost) equal with the case GC is enabled at begging. But it doesn't
seems so from our experience.

Do anyone know why there could be significant difference on memory
usage because of timing of GC? It might be a question on Ruby rather
than Unicorn, though, I thought even just sharing my experience could
be worth to someone here.


Tatsuya Ono

From paihungchen at hotmail.com  Mon Oct 10 16:34:19 2011
From: paihungchen at hotmail.com (Pai-Hung Chen)
Date: Mon, 10 Oct 2011 20:34:19 +0000 (UTC)
Subject: How to automate the restarting of Unicorn?
References: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>
	<D0C8FD0B85DE4305A1EC0EE8B872A1A7@gmail.com>
	<4E928ADD.8040900@whitepages.com>
Message-ID: <loom.20111010T222728-376@post.gmane.org>

> On 10/10/2011 08:04 AM, Devin Ben-Hur wrote:

> >> My question is: By the time the "before_exec" hook is executed, is it
> >> guaranteed that unicorn.pid.oldbin ahas lready created (otherwise we
> >> have a racing condition here)? Or is there a better way to achieve
> >> what I want?
> > I'm not 100% positive, but about 98% -- yes, you can count on the fact that
the *.oldbin file will exist on
> > disk before the before_exec block is executed. Eric can confirm this, but
I've never had a problem with it...
> No need to rely on authority, just read the source: 
> https://github.com/defunkt/unicorn/blob/master/lib/unicorn/http_server.rb

Thanks for the pointer. The current source code clearly shows before_exec is
called after the .oldbin file is created. I'd like to know if this is considered
an "invariant" going forward. Could someone in the "authority" help?

Thanks,
Pai-Hung




From normalperson at yhbt.net  Mon Oct 10 17:27:41 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 10 Oct 2011 14:27:41 -0700
Subject: How to automate the restarting of Unicorn?
In-Reply-To: <loom.20111010T222728-376@post.gmane.org>
References: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>
	<D0C8FD0B85DE4305A1EC0EE8B872A1A7@gmail.com>
	<4E928ADD.8040900@whitepages.com>
	<loom.20111010T222728-376@post.gmane.org>
Message-ID: <20111010212741.GA3828@dcvr.yhbt.net>

Pai-Hung Chen <paihungchen at hotmail.com> wrote:
> > On 10/10/2011 08:04 AM, Devin Ben-Hur wrote:
> > >> My question is: By the time the "before_exec" hook is executed, is it
> > >> guaranteed that unicorn.pid.oldbin ahas lready created (otherwise we
> > >> have a racing condition here)? Or is there a better way to achieve
> > >> what I want?
> > > I'm not 100% positive, but about 98% -- yes, you can count on the fact that
> the *.oldbin file will exist on
> > > disk before the before_exec block is executed. Eric can confirm this, but
> I've never had a problem with it...
> > No need to rely on authority, just read the source: 
> > https://github.com/defunkt/unicorn/blob/master/lib/unicorn/http_server.rb

100% correct, source code never lies.

> Thanks for the pointer. The current source code clearly shows before_exec is
> called after the .oldbin file is created. I'd like to know if this is considered
> an "invariant" going forward.

Yes, there's no way to safely handle the pid file otherwise because of
race conditions you mentioned.  The oldbin pid file must exist because
the new process (which calls before_exec) can clobber the regular pid
file once fork is called.

> Could someone in the "authority" help?

Fwiw, I'm only reluctantly an "authority".  I'm against the notion of
authority.  I am and forever will be nobody :)

From normalperson at yhbt.net  Mon Oct 10 17:53:24 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 10 Oct 2011 14:53:24 -0700
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <CAHBuKRjBedCTDi1yPC4J3+tmzpxLFCkFrm-gyDrTPTF7BOkFHQ@mail.gmail.com>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
	<20111004225305.GA5373@dcvr.yhbt.net>
	<CAGh4DjmVsCMJd2GKDo2evgsn2-TD4O6xiPgxtphc6a7fucR1UQ@mail.gmail.com>
	<CAHBuKRjBedCTDi1yPC4J3+tmzpxLFCkFrm-gyDrTPTF7BOkFHQ@mail.gmail.com>
Message-ID: <20111010215324.GA6378@dcvr.yhbt.net>

Tatsuya Ono <ononoma at gmail.com> wrote:
> I don't actually understand is why GC.disable solution could introduce
> more memory leak. If I simplify the problem, the code is something
> like bellow:
> 
> ---------------
> GC.disable
> (do something)
> GC.enable
> GC.start
> ---------------
> 
> When the code block finishes, I expect that memory size should be
> (almost) equal with the case GC is enabled at begging. But it doesn't
> seems so from our experience.
> 
> Do anyone know why there could be significant difference on memory
> usage because of timing of GC? It might be a question on Ruby rather
> than Unicorn, though, I thought even just sharing my experience could
> be worth to someone here.

Basically, the free(3) function in the C standard library does not
guarantee memory is released back to the kernel (speed vs memory usage
tradeoff).

There was discussion of this on the usp.ruby mailing list starting at
Message-ID: 20110914234917.GA2480 at dcvr.yhbt.net

usp.ruby archives are at http://bogomips.org/usp.ruby/archives/2011.mbox.gz

From paihungchen at hotmail.com  Mon Oct 10 18:18:00 2011
From: paihungchen at hotmail.com (Pai-Hung Chen)
Date: Mon, 10 Oct 2011 22:18:00 +0000 (UTC)
Subject: How to automate the restarting of Unicorn?
References: <CA+rii7H2gNdoWipzrhbgTu0G4H+3c9pS-PqA1jO-Cn-uGSsHxQ@mail.gmail.com>
	<D0C8FD0B85DE4305A1EC0EE8B872A1A7@gmail.com>
	<4E928ADD.8040900@whitepages.com>
	<loom.20111010T222728-376@post.gmane.org>
	<20111010212741.GA3828@dcvr.yhbt.net>
Message-ID: <loom.20111011T001229-840@post.gmane.org>

Eric Wong wrote:

> Yes, there's no way to safely handle the pid file otherwise because of
> race conditions you mentioned.  The oldbin pid file must exist because
> the new process (which calls before_exec) can clobber the regular pid
> file once fork is called.

Thanks for the confirmation :) Much appreciated!

Pai-Hung


From ononoma at gmail.com  Mon Oct 10 19:03:23 2011
From: ononoma at gmail.com (Tatsuya Ono)
Date: Tue, 11 Oct 2011 00:03:23 +0100
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <20111010215324.GA6378@dcvr.yhbt.net>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
	<20111004225305.GA5373@dcvr.yhbt.net>
	<CAGh4DjmVsCMJd2GKDo2evgsn2-TD4O6xiPgxtphc6a7fucR1UQ@mail.gmail.com>
	<CAHBuKRjBedCTDi1yPC4J3+tmzpxLFCkFrm-gyDrTPTF7BOkFHQ@mail.gmail.com>
	<20111010215324.GA6378@dcvr.yhbt.net>
Message-ID: <CAHBuKRii9X+b4V0ehV+4cC_UgKPEuYdk-WH1CtvdO4A0rkjrqw@mail.gmail.com>

Thanks Eric for the feedback.

I actually had read that email and I think I understand it. But what I
am experiencing seems a different story. Our rails app uses around
250MB memory usually. After applying this patch and calling
GC.disabled on after_fork, the usage of memory increases on every
request and goes up to 1GB easily.

However, yes, I must say that I need to test more carefully. Let me
come back later. I am going to have some stress test and monitor if
Unicorn introduces swapping on VM with this solution. Hopefully I can
do it tomorrow or later this week.


Tatsuya

On 10 October 2011 22:53, Eric Wong <normalperson at yhbt.net> wrote:
> Tatsuya Ono <ononoma at gmail.com> wrote:
>> I don't actually understand is why GC.disable solution could introduce
>> more memory leak. If I simplify the problem, the code is something
>> like bellow:
>>
>> ---------------
>> GC.disable
>> (do something)
>> GC.enable
>> GC.start
>> ---------------
>>
>> When the code block finishes, I expect that memory size should be
>> (almost) equal with the case GC is enabled at begging. But it doesn't
>> seems so from our experience.
>>
>> Do anyone know why there could be significant difference on memory
>> usage because of timing of GC? It might be a question on Ruby rather
>> than Unicorn, though, I thought even just sharing my experience could
>> be worth to someone here.
>
> Basically, the free(3) function in the C standard library does not
> guarantee memory is released back to the kernel (speed vs memory usage
> tradeoff).
>
> There was discussion of this on the usp.ruby mailing list starting at
> Message-ID: 20110914234917.GA2480 at dcvr.yhbt.net
>
> usp.ruby archives are at http://bogomips.org/usp.ruby/archives/2011.mbox.gz
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying
>

From neil at dist.ro  Mon Oct 10 18:25:46 2011
From: neil at dist.ro (neil at dist.ro)
Date: Tue, 11 Oct 2011 11:25:46 +1300
Subject: Home directory for workers
Message-ID: <20111010222545.GA30758@dist.ro>


When unicorn is started as the root user and the worker processes run as as an
unprivileged user because of the "user" option in unicorn.conf then the home
directory of the worker processes is still "/root".  This causes trouble with
GPGME at least, which expects to find encryption keys in the user's home
directory.

Apologies in advance if this has been fixed since 4.1.1.

- neil


From normalperson at yhbt.net  Tue Oct 11 04:16:01 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Tue, 11 Oct 2011 08:16:01 +0000
Subject: Home directory for workers
In-Reply-To: <20111010222545.GA30758@dist.ro>
References: <20111010222545.GA30758@dist.ro>
Message-ID: <20111011081601.GA4208@dcvr.yhbt.net>

neil at dist.ro wrote:
> When unicorn is started as the root user and the worker processes run
> as as an unprivileged user because of the "user" option in
> unicorn.conf then the home directory of the worker processes is still
> "/root".  This causes trouble with GPGME at least, which expects to
> find encryption keys in the user's home directory.

You mean the ENV["HOME"] value?  This typically isn't changed when
changing privileges in other daemons like nginx.  Changing ENV["HOME"]
automatically inside unicorn has the potential to break existing setups
badly, so it won't be done.

However, you can set it in your after_fork hook (or anywhere else in
your unicorn config file)

  after_fork do |server,worker|
    ENV["HOME"] = "/home/user"
  end

You can even set it in the shell when starting unicorn:

  HOME=/home/user unicorn -c unicorn.conf.rb

From ononoma at gmail.com  Wed Oct 12 12:00:54 2011
From: ononoma at gmail.com (Tatsuya Ono)
Date: Wed, 12 Oct 2011 17:00:54 +0100
Subject: Peformance up - using OobGC & GC.disable
In-Reply-To: <CAHBuKRii9X+b4V0ehV+4cC_UgKPEuYdk-WH1CtvdO4A0rkjrqw@mail.gmail.com>
References: <CAGh4DjnGymyQkvSt3rAd3n6J8xtPHPw7YTSN3Vg0q+Y2Ym57zw@mail.gmail.com>
	<20111004225305.GA5373@dcvr.yhbt.net>
	<CAGh4DjmVsCMJd2GKDo2evgsn2-TD4O6xiPgxtphc6a7fucR1UQ@mail.gmail.com>
	<CAHBuKRjBedCTDi1yPC4J3+tmzpxLFCkFrm-gyDrTPTF7BOkFHQ@mail.gmail.com>
	<20111010215324.GA6378@dcvr.yhbt.net>
	<CAHBuKRii9X+b4V0ehV+4cC_UgKPEuYdk-WH1CtvdO4A0rkjrqw@mail.gmail.com>
Message-ID: <CAHBuKRhLiu260cWFcqzsFhETKQ4Nc3GQ+x+fxDL7dg0sG+XBvQ@mail.gmail.com>

Yes, you are right, Eric. The usage of memory stops increasing at a
certain point. Besides I do not see any significant page I/O with it.

I give the patch go for our live service without the UnicornKiller. I
will report if we experience any issues occurred in the wild.

Thanks Yuichi again for submitting the patch and sharing your knowledge.

By the way, I tested this with Rails 2.3/Ruby 1.8.7/FreeBSD 8.2


Tatsuya

On 11 October 2011 00:03, Tatsuya Ono <ononoma at gmail.com> wrote:
> Thanks Eric for the feedback.
>
> I actually had read that email and I think I understand it. But what I
> am experiencing seems a different story. Our rails app uses around
> 250MB memory usually. After applying this patch and calling
> GC.disabled on after_fork, the usage of memory increases on every
> request and goes up to 1GB easily.
>
> However, yes, I must say that I need to test more carefully. Let me
> come back later. I am going to have some stress test and monitor if
> Unicorn introduces swapping on VM with this solution. Hopefully I can
> do it tomorrow or later this week.
>
>
> Tatsuya
>
> On 10 October 2011 22:53, Eric Wong <normalperson at yhbt.net> wrote:
>> Tatsuya Ono <ononoma at gmail.com> wrote:
>>> I don't actually understand is why GC.disable solution could introduce
>>> more memory leak. If I simplify the problem, the code is something
>>> like bellow:
>>>
>>> ---------------
>>> GC.disable
>>> (do something)
>>> GC.enable
>>> GC.start
>>> ---------------
>>>
>>> When the code block finishes, I expect that memory size should be
>>> (almost) equal with the case GC is enabled at begging. But it doesn't
>>> seems so from our experience.
>>>
>>> Do anyone know why there could be significant difference on memory
>>> usage because of timing of GC? It might be a question on Ruby rather
>>> than Unicorn, though, I thought even just sharing my experience could
>>> be worth to someone here.
>>
>> Basically, the free(3) function in the C standard library does not
>> guarantee memory is released back to the kernel (speed vs memory usage
>> tradeoff).
>>
>> There was discussion of this on the usp.ruby mailing list starting at
>> Message-ID: 20110914234917.GA2480 at dcvr.yhbt.net
>>
>> usp.ruby archives are at http://bogomips.org/usp.ruby/archives/2011.mbox.gz
>> _______________________________________________
>> Unicorn mailing list - mongrel-unicorn at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
>> Do not quote signatures (like this one) or top post when replying
>>
>

From madsheeppl at gmail.com  Fri Oct 14 03:33:02 2011
From: madsheeppl at gmail.com (Marcin Stecki)
Date: Fri, 14 Oct 2011 09:33:02 +0200
Subject: Hoptoad setup.
Message-ID: <CAF-xwzSFsgc1ehuaM71WpqjoQQVy9Axn0aCTRjGnLENh=eHjmw@mail.gmail.com>

Hi,

In my ror 3.0.10 app Unicorn somehow causes my application to show
errors on staging like it was development environment (with backtrace
and everything) instead of sending them to hoptoad. This is strange -
same app on mongrel shows custom 500 page and sends errors to hoptoad
as expected.

Rails configuration seems to be ok, works on mongrel and passenger.
To lunch my app i'm using pretty basic command:


"bundle exec unicorn_rails -c config/unicorn.rb -D -E staging"



nothing fancy inside the config:


#config/unicorn.rb

rails_env = ENV["RAILS_ENV"] || "production"
user_name = 'my_app_name'
app_path = "/home/#{user_name}/app/current"
shared_path = "/home/#{user_name}/app/shared"

worker_processes rails_env == 'production' ? 6 : 2

listen 9999, :tcp_nopush => true

preload_app true

timeout 30

pid "#{app_path}/tmp/pids/unicorn.my_app_name.pid"

working_directory app_path

user user_name, user_name

stderr_path "#{shared_path}/log/unicorn.stderr.log"
stdout_path "#{shared_path}/log/unicorn.stdout.log"

before_fork do |server, worker|
  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.connection.disconnect!
  end

  old_pid = "#{app_path}/tmp/pids/unicorn.my_app_name.pid.oldbin"
  if File.exists?(old_pid) && server.pid != old_pid
    begin
      Process.kill("QUIT", File.read(old_pid).to_i)
    rescue Errno::ENOENT, Errno::ESRCH
    end
  end
end

after_fork do |server, worker|
  if defined?(ActiveRecord::Base)
    ActiveRecord::Base.establish_connection
  end
end



Any help w'd be appreciated.
Thx, Madsheep.

From normalperson at yhbt.net  Fri Oct 14 04:45:04 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 14 Oct 2011 08:45:04 +0000
Subject: Hoptoad setup.
In-Reply-To: <CAF-xwzSFsgc1ehuaM71WpqjoQQVy9Axn0aCTRjGnLENh=eHjmw@mail.gmail.com>
References: <CAF-xwzSFsgc1ehuaM71WpqjoQQVy9Axn0aCTRjGnLENh=eHjmw@mail.gmail.com>
Message-ID: <20111014084504.GA24915@dcvr.yhbt.net>

Marcin Stecki <madsheeppl at gmail.com> wrote:
> In my ror 3.0.10 app Unicorn somehow causes my application to show
> errors on staging like it was development environment (with backtrace
> and everything) instead of sending them to hoptoad. This is strange -
> same app on mongrel shows custom 500 page and sends errors to hoptoad
> as expected.
> 
> Rails configuration seems to be ok, works on mongrel and passenger.
> To lunch my app i'm using pretty basic command:
> 
> 
> "bundle exec unicorn_rails -c config/unicorn.rb -D -E staging"

I haven't looked at hoptoad before, but does setting RACK_ENV=none
help?

  RACK_ENV=none bundle exec unicorn_rails -c config/unicorn.rb -D -E staging

Or even swapping "unicorn_rails" for plain "unicorn":

  RACK_ENV=none RAILS_ENV=staging bundle exec unicorn -c config/unicorn.rb -D

"unicorn_rails" was mainly designed for Rails 2.2 and earlier,
Rack-capable versions of Rails are probably better served by just
"unicorn"

Maybe others on this list have more experience with this particular
combination, not much of a Rails user myself...

From nasydasisaaa79nsnm at yahoo.de  Wed Oct 19 03:44:10 2011
From: nasydasisaaa79nsnm at yahoo.de (Louis)
Date: Wed, 19 Oct 2011 15:44:10 +0800
Subject: =?GB2312?B?QW5pbWF0ZWQgTW92aWUvVFYgU2VyaWVzIA==?=
	=?GB2312?B?LSBDYXJ0b29uIE1vdmllL1RWIFNlcmllcw==?=
	=?GB2312?B?IC0gM0QvMkQgQW5pbWF0aW9uIFNlcnZpYw==?= =?GB2312?B?ZXM=?=
Message-ID: <mailman.0.1319022415.1616.mongrel-unicorn@rubyforge.org>

You are receiving this email because we wish you to use our 3D/2D Animated Movie/TV Series Services.
 
We are a China based Animated Movie/TV Series Studio. with the technical, our studio is a animation studio with the technical, creative and production capabilities to create a new generation of animated feature films, merchandise and other related products. Our objective is to combine proprietary technology and world-class creative talent to develop computer-animated feature films with memorable characters and heartwarming stories that appeal to audiences of all ages. We utilize the finest equipment available in the industry, offer efficient data delivery and unrivaled quality and work until the client is fully satisfied with the end product. 
 
Core Offerings
2D Animation
3D Animation
4D Animation
Cell Animation
Cartoon Animation
Animated Movies 
Animated TV Series
Architecture Visualization 
Character Animation 
Animated Commercial 
Animated Presentation 
Walkthrough Animation 
Flash Presentation 
Logo Animation 
Animated Wallpapers 
Animated Graphics 
 
We are also looking for agents who can represent us in USA and Europe in order to gain more Animated Movie orders.
 
Best regards,
Louis
Louisamosen Animation Services
Contact: ibanicontact at yeah.net


















Pls send address to koremoveideite at yeah.net  for remove

                                                                                                                                                                 

From infomail-5 at mint.razor.jp  Mon Oct 24 13:13:26 2011
From: infomail-5 at mint.razor.jp (=?ISO-2022-JP?B?GyRCNWE/TT5wSnMkTiFKM3QhSyVTJTglTSU5JUglaSU5JUglNyU5JUYlYCU6GyhC?=)
Date: 25 Oct 2011 02:13:26 +0900
Subject: =?ISO-2022-JP?B?GyRCOl9CcCVvITwlKyE8NV5KZ0IuSnMbKEIhGyRCIVolRyE8JT9Gfk5PNkhMM0JnTkw8dUNtJE4kPyRhIVslYSVrJV4lLBsoQlNPSE8bJEJAODNoJUslZSE8JTkbKEI=?=
Message-ID: <20111024171326.8767.qmail@www20.bizmail.jp>

??????SOHO??????14,462??2011?10?? ??????:95,438??????????????????????

???????????????????????????????????????????? 
???????? Please e-mail the delivery stop here.? kyo at biz-career.rulez.jp
?1?  ????SOHO????????????????????????????????
?PR????????????????????????????????
?????????????????! SOHO???????????????!
????????????????????!!???????????????????!
????????????????????????????????!?

??? !! ?????????? ? http://community.rulez.jp/
?PR????????????????????????????????
???????10???????????????
 
??????????????????????????
??SOHO??????????3???????????????
??????????????????????????

?1????????????????! ????????????!
  ?????????????????????????????
 
?2?????????????????????????! ??????!
  ?SOHO????????????????!
 
?3??????????????????????!?????!
  ????????????????????!
      ?
      ? ?????????
      ? ???????! ??????????!! ?
      ?
      ?????  http://community.rulez.jp/
 
????????????????
?????????????????
 
??????????????????????????
????SOHO??????!!
 
??????????????
 
1.???? ? 18,500 ? 5,550?
2.?????????????? ? 10,550 ? 45,900?
3.????????? ? 1,000 ? 31,531?
4.????????? 6 ? 42,000?
5.?????????? 4 ? 13,500?
6.???????????????? ? 90 ? 45,000?
 
????????183,481?????
???????????????????(1?2?4????)???????!!
 
     ?  http://community.rulez.jp/
     ?    ?(??????????)
 
?????????????????????????
???????????????! ????????????!!
 
???????????????????????????????????
?????????????????????????SOHO??????????
??????????????????????????????????????????
???????????????????????????????????

?<???>??????????????
??????????????????????????????????????? 
??????????????????????

??????????????????????????????????
???????????????????????????

???????????????????????????????????????????? 
???????? Please e-mail the delivery stop here.? kyo at biz-career.rulez.jp

???????????????????????????????????
??????????????)??????????????Web??????????
???????????????????????????????????
Copyright (c) 1999  ???????????????????????All rights reserved.???????

From johnjosephbachir at gmail.com  Mon Oct 24 20:03:58 2011
From: johnjosephbachir at gmail.com (John Bachir)
Date: Mon, 24 Oct 2011 20:03:58 -0400
Subject: =?utf-8?B?UmU6IOWcqOWuheODr+ODvOOCq+ODvOaApeWLn+mAn+WgsSHjgJA=?=
	=?utf-8?B?44OH44O844K/5YWl5Yqb5qWt5YuZ5aSn6YeP5Y+X5rOo44Gu44Gf?=
	=?utf-8?B?44KB44CR44Oh44Or44Oe44KsU09IT+eUn+a0u+ODi+ODpeODvA==?=
	=?utf-8?B?44K5?=
In-Reply-To: <20111024171326.8767.qmail@www20.bizmail.jp>
References: <20111024171326.8767.qmail@www20.bizmail.jp>
Message-ID: <EFFBE2B5-9828-4001-B6B6-6B61A4C3871F@gmail.com>

That is beautiful.


On Oct 24, 2011, at 1:13 PM, ?????????????????????<infomail-5 at mint.razor.jp> wrote:

> ??????SOHO??????14,462??2011?10?? ??????:95,438??????????????????????
> 
> ???????????????????????????????????????????? 
> ???????? Please e-mail the delivery stop here.? kyo at biz-career.rulez.jp
> ?1?  ????SOHO????????????????????????????????
> ?PR????????????????????????????????
> ?????????????????! SOHO???????????????!
> ????????????????????!!???????????????????!
> ????????????????????????????????!?
> 
> ??? !! ?????????? ? http://community.rulez.jp/
> ?PR????????????????????????????????
> ???????10???????????????
> 
> ??????????????????????????
> ??SOHO??????????3???????????????
> ??????????????????????????
> 
> ?1????????????????! ????????????!
>  ?????????????????????????????
> 
> ?2?????????????????????????! ??????!
>  ?SOHO????????????????!
> 
> ?3??????????????????????!?????!
>  ????????????????????!
>      ?
>      ? ?????????
>      ? ???????! ??????????!! ?
>      ?
>      ?????  http://community.rulez.jp/
> 
> ????????????????
> ?????????????????
> 
> ??????????????????????????
> ????SOHO??????!!
> 
> ??????????????
> 
> 1.???? ? 18,500 ? 5,550?
> 2.?????????????? ? 10,550 ? 45,900?
> 3.????????? ? 1,000 ? 31,531?
> 4.????????? 6 ? 42,000?
> 5.?????????? 4 ? 13,500?
> 6.???????????????? ? 90 ? 45,000?
> 
> ????????183,481?????
> ???????????????????(1?2?4????)???????!!
> 
>     ?  http://community.rulez.jp/
>     ?    ?(??????????)
> 
> ?????????????????????????
> ???????????????! ????????????!!
> 
> ???????????????????????????????????
> ?????????????????????????SOHO??????????
> ??????????????????????????????????????????
> ???????????????????????????????????
> 
> ?<???>??????????????
> ??????????????????????????????????????? 
> ??????????????????????
> 
> ??????????????????????????????????
> ???????????????????????????
> 
> ???????????????????????????????????????????? 
> ???????? Please e-mail the delivery stop here.? kyo at biz-career.rulez.jp
> 
> ???????????????????????????????????
> ??????????????)??????????????Web??????????
> ???????????????????????????????????
> Copyright (c) 1999  ???????????????????????All rights reserved.???????
> _______________________________________________
> Unicorn mailing list - mongrel-unicorn at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-unicorn
> Do not quote signatures (like this one) or top post when replying

From normalperson at yhbt.net  Mon Oct 31 18:24:37 2011
From: normalperson at yhbt.net (Eric Wong)
Date: Mon, 31 Oct 2011 15:24:37 -0700
Subject: Wanted: OobGC testers on Ruby 1.9.3
Message-ID: <20111031222437.GA32156@dcvr.yhbt.net>

I originally brought this up in August but didn't get any response:

  http://mid.gmane.org/20110822202327.GB2874 at dcvr.yhbt.net

Now Ruby 1.9.3-p0 is officially released, I'm (still) curious to know if
OobGC still helps *your* *application(s)* given the new lazy-sweep GC in
Ruby 1.9.3.