Rails - Sep 2005 - [BUG] Quick Fix for SCGI leaked DB connections

Hi Folks,

I believe I tracked down the problem with the leaked DB connections.  The
simple fix is to put:

ActiveRecord::Base.threaded_connections = false

In your environment.rb file right before environment.rb does any
ActiveRecord use.  For example, here''s mine:

ActiveRecord::Base.threaded_connections = false
ActiveRecord::Base.configurations
File.open("#{RAILS_ROOT}/config/database.yml") { |f| YAML::load(f) }
ActiveRecord::Base.establish_connection
...

This solves the problem by telling AR to store it''s DB connections in a
different place.  Normally it stores them in
Thread.current[''active_connections''] which means that, in
single threaded
operation you don''t really get threaded_connections, and in
multi-threaded
operation you get a heinous number of connections.

=== Implications ==Since scgi_rails runs Rails inside a Synchronize block, you
are *sort of*
getting sequential operation.  The way AR uses Thread.current though means
that if you want multiple threads to do your work, then AR is actually
going to cause this exact leak problem.  So, the only way around it is to:

1)  Manage the connections for AR inside scgi_rails.
2)  Turn off this "threaded" feature and just use the one connection.
3)  Develop a pooling method for AR.

The above fix does #2 so there may be problems with your performance, but
it means that you''ll only have 1 DB connection for each child*AR class
connection.  10 children with 3 AR classes doing their own connections
will be 30 total.

I''ll look into the results of the other two.  Also, is it worth just
having scgi_rails turn this off so that people''s Rails setups work out
of
the box?

Please test and give me the results in your configuration.  Thanks.

Zed A. Shaw
http://www.zedshaw.com/

I would prefer that this be handler in scgi_rails and not require any mods
to the rails app. This makes it easier to deploy a rails app to another
server.

Curt

On 9/29/05, zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org
<zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
>
> Hi Folks,
>
> I believe I tracked down the problem with the leaked DB connections. The
> simple fix is to put:
>
> ActiveRecord::Base.threaded_connections = false
>
> In your environment.rb file right before environment.rb does any
> ActiveRecord use. For example, here''s mine:
>
> ActiveRecord::Base.threaded_connections = false
> ActiveRecord::Base.configurations >
File.open("#{RAILS_ROOT}/config/database.yml") { |f| YAML::load(f) }
> ActiveRecord::Base.establish_connection
> ...
>
> This solves the problem by telling AR to store it''s DB connections
in a
> different place. Normally it stores them in
> Thread.current[''active_connections''] which means that, in
single threaded
> operation you don''t really get threaded_connections, and in
multi-threaded
> operation you get a heinous number of connections.
>
> === Implications ==> Since scgi_rails runs Rails inside a Synchronize
block, you are *sort of*
> getting sequential operation. The way AR uses Thread.current though means
> that if you want multiple threads to do your work, then AR is actually
> going to cause this exact leak problem. So, the only way around it is to:
>
> 1) Manage the connections for AR inside scgi_rails.
> 2) Turn off this "threaded" feature and just use the one
connection.
> 3) Develop a pooling method for AR.
>
> The above fix does #2 so there may be problems with your performance, but
> it means that you''ll only have 1 DB connection for each child*AR
class
> connection. 10 children with 3 AR classes doing their own connections
> will be 30 total.
>
> I''ll look into the results of the other two. Also, is it worth
just
> having scgi_rails turn this off so that people''s Rails setups work
out of
> the box?
>
> Please test and give me the results in your configuration. Thanks.
>
> Zed A. Shaw
> http://www.zedshaw.com/
>
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 29, 2005, at 11:45 AM, zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org
wrote:
> So, the only way around it is to:
> 1)  Manage the connections for AR inside scgi_rails.
> 2)  Turn off this "threaded" feature and just use the one
connection.
> 3)  Develop a pooling method for AR.
2 until 3 hits Rails.

Thanks Zed!
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDPDznAQHALep9HFYRAsKmAJ9ThpbuKIlsub3Uqo8hvKPVVsT07ACfQlVd
048aBJ1GBQfTeyfvgdHpH68=FyMw
-----END PGP SIGNATURE-----