DBI persistence problem

[prev] [thread] [next] [Date index for 2004/12/02]

From: Richard N. Fogle
Subject: DBI persistence problem
Date: 01:00 on 02 Dec 2004
--=-8lKS1bwD0BtbD9NwDSH0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hello,

We're having quite the time with CGIs being called in mod_perl, listed
below is an example of the DBI connection code:

----SNIP----
use DBI
my $write_dbh =
DBI->connect("DBI:mysql:writeDB:192.168.1.10","foouser","foopass") ||
die $DBI::errstr;
my $read_dbh;
if ( int(rand(4)) ) { $read_dbh =
DBI->connect("DBI:mysql:readDB1::192.168.1.20","foouser","foopass") ||
se
tReadToWrite($read_dbh); }
else { $read_dbh =
DBI->connect("DBI:mysql:readDB2:192.168.1.21","foouser","foopass") ||
setReadToWrite($r
ead_dbh); }
----SNIP----

Basically, we have one MySQL cluster setup for reads and the other
cluster for writes - the reads cluster alternates between master and
slave.  This works fine.  The problem we're having is each time the CGI
is called it seems to make a persistent connection to the database
despite the fact that we have a $dbh->disconnect(); at the end of the
code.  This causes the application to work well for a period of time,
but it will quickly run the databases out of processes (despite raising
max_connections to 1024+) and when we go into MySQL to look at the
process list it shows a bunch of sleeping connections!  

We have no real explanation other than perhaps mod_perl, or our (mis)use
thereof, may be adding to this.  We have mod_perl loaded in apache but
nothing in our startup.PL, nor anything special in httpd.conf.
Appreciate it if anyone has had this problem in the past and could shed
some light on what is going on.  This is a very high-load application
and there is no way the webservers would survive without mod_perl.  The
server-side app consists of about 20 scripts, each with their own
connect string as described above and their own disconnect strings.  We
tried placing the connect strings in startup.PL and into a seperate file
that gets shared but that just drives the load average through the roof.
Appreciate any assistance anyone could provide, is mod_perl caching
these scripts and making the database connections persistent?

Regards,

Rich




--=-8lKS1bwD0BtbD9NwDSH0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.2.3">
</HEAD>
<BODY>
Hello,<BR>
<BR>
We're having quite the time with CGIs being called in mod_perl, listed below is an example of the DBI connection code:<BR>
<BR>
----SNIP----<BR>
use DBI<BR>
my $write_dbh = DBI-&gt;connect(&quot;DBI:mysql:writeDB:192.168.1.10&quot;,&quot;foouser&quot;,&quot;foopass&quot;) || die $DBI::errstr;<BR>
my $read_dbh;<BR>
if ( int(rand(4)) ) { $read_dbh = DBI-&gt;connect(&quot;DBI:mysql:readDB1::192.168.1.20&quot;,&quot;foouser&quot;,&quot;foopass&quot;) || se<BR>
tReadToWrite($read_dbh); }<BR>
else { $read_dbh = DBI-&gt;connect(&quot;DBI:mysql:readDB2:192.168.1.21&quot;,&quot;foouser&quot;,&quot;foopass&quot;) || setReadToWrite($r<BR>
ead_dbh); }<BR>
----SNIP----<BR>
<BR>
Basically, we have one MySQL cluster setup for reads and the other cluster for writes - the reads cluster alternates between master and slave.&nbsp; This works fine.&nbsp; The problem we're having is each time the CGI is called it seems to make a persistent connection to the database despite the fact that we have a $dbh-&gt;disconnect(); at the end of the code.&nbsp; This causes the application to work well for a period of time, but it will quickly run the databases out of processes (despite raising max_connections to 1024+) and when we go into MySQL to look at the process list it shows a bunch of sleeping connections!&nbsp; <BR>
<BR>
We have no real explanation other than perhaps mod_perl, or our (mis)use thereof, may be adding to this.&nbsp; We have mod_perl loaded in apache but nothing in our startup.PL, nor anything special in httpd.conf.&nbsp; Appreciate it if anyone has had this problem in the past and could shed some light on what is going on.&nbsp; This is a very high-load application and there is no way the webservers would survive without mod_perl.&nbsp; The server-side app consists of about 20 scripts, each with their own connect string as described above and their own disconnect strings.&nbsp; We tried placing the connect strings in startup.PL and into a seperate file that gets shared but that just drives the load average through the roof.&nbsp; Appreciate any assistance anyone could provide, is mod_perl caching these scripts and making the database connections persistent?<BR>
<BR>
Regards,<BR>
<BR>
Rich<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>

--=-8lKS1bwD0BtbD9NwDSH0--

DBI persistence problem
Richard N. Fogle 01:00 on 02 Dec 2004

Re: DBI persistence problem
Malcolm J Harwood 22:36 on 01 Dec 2004

Re: DBI persistence problem
Perrin Harkins 22:39 on 01 Dec 2004

Re: DBI persistence problem
Richard N. Fogle 01:26 on 02 Dec 2004

Re: DBI persistence problem
Malcolm J Harwood 23:10 on 01 Dec 2004

Re: DBI persistence problem
Richard N. Fogle 23:48 on 01 Dec 2004

Re: DBI persistence problem
Perrin Harkins 19:16 on 02 Dec 2004

Re: DBI persistence problem
Rob Mueller 19:46 on 02 Dec 2004

Generated at 11:26 on 21 Dec 2004 by mariachi v0.52