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.
