Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Subject: Re: Mixed Children on amd64
From: Vincent Veyron <vv.lists@wanadoo.fr>
To: mod_perl list <modperl@perl.apache.org>
In-Reply-To: <4C98C66E.40207@ice-sa.com>
References: <1285023622.5547.2.camel@localhost>
	 <AANLkTintaZw-=7hLSzB=v5LpnWnS+dmtAQu-doCae4gX@mail.gmail.com>
	 <4C98C66E.40207@ice-sa.com>
Content-Type: text/plain; charset=iso-8859-15
Date: Tue, 21 Sep 2010 23:57:43 +0200
Message-Id: <1285106263.3153.95.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi, 

Replying here to both of you for convenience

Le mardi 21 septembre 2010 � 16:51 +0200, Andr� Warnier a �crit :
> Perrin Harkins wrote:
> > 
> > Are these just two virtual servers running from the same httpd.conf
> > and server binaries?  How does each one know which database to use?

Each server has its own httpd.conf and binaries, compiled in different
directories. Both processes use the same perl modules. 

After login, a headerParser validates the session; demo users have a
'demo_' prefix appended to their name, and in that case the cached
database connection used is the demo one.

Below is the relevant code in the headerparser:
======================================================================
#list of database names (demo, main)
my @databases = $r->dir_config->get('db_name');

#identity of demo user  
my $demo_username = $r->dir_config('demo_username');

#demo user connects to demo db
my ($db_type,
    $db_name,
    $db_user,
    $db_pwd,
    %attributes ) =
( $r->dir_config('db_type'),
  ( $r->pnotes('session')->{username} =~ /$demo_username/ ) ?
$databases[1] : $databases[0],
  $r->dir_config('db_user'),
  $r->dir_config('db_pwd'),
  $r->dir_config->get('attributes') );
    
eval {

    $dbh = DBI->connect_cached( "DBI:$db_type:dbname=$db_name",
$db_user, $db_pwd, \%attributes );

}
=====================================================================

> Sometimes, a problem in the logic, which was there all the time but never caused any 
> actual problem because it was very unlikely, can become acute because of an apparently 
> unrelated change.
> For example, events that almost never occurred "simultaneously" on a slower processor or 
> with less memory, now start to happen "simultaneously" because the processor is much 
> faster, or because there is more memory available to start more processes at the same time.
> And never mind the fact that a modern 64-bit processor is likely to have several cores, 
> allowing it to actually run more than one process at the same time.
> So something which before never happened, or happened only once or twice a year, and was 
> not reproducible and thus was ignored as a "cosmic ray hitting the CPU", now happens 2 or 
> 3 times a day and cannot be ignored anymore.
> The original description of the problem really makes me think of something like that.
> I would bet my shirt that if you considered 2 instances of this application side by side, 
> and imagined that they do each step in parallel, there would be a point where you would 
> notice that something could go wrong.
> And with a faster CPU, things that can go wrong, do go wrong faster.
> 

Indeed, this machine has more memory and a faster processor than the
previous ones, but I have very low traffic. Below is the result of `top`
(the machine was facing the internet until yesterday). As you can see,
it's not stressed by any means.
=====================================================================
top - 21:19:18 up 35 days, 13:24,  1 user,  load average: 0.00, 0.00,
0.00
Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,
0.0%st
Mem:   2028176k total,  1544980k used,   483196k free,   274400k buffers
Swap:  1044216k total,        0k used,  1044216k free,  1031144k cached
=====================================================================

The previous machines had similar statistics, but users noticed the
problem as soon as I put this one up.