I'm not quite ready to declare victory, but I think installing DBD from
source and getting more recent versions of DBD was the problem, and it
seems there's a lot of little things going wrong with DBD.
What's going on there? When did DBD::mysql become so problematic? It
used to run so flawless, even back in the day when you would have to
choose between mysql and msql during the install...
Anyway if anyone is having similar problems then try upgrading from source.
Tosh
On 7/22/64 8:59 PM, Tosh Cooey wrote:
Hi Tuomo, thank-you that was really helpful.
I'm running prefork it seems. Here's the list if that's helpful:
core.c
mod_log_config.c
mod_logio.c
prefork.c
http_core.c
mod_so.c
Also perhaps helpful is that I'm on Ubuntu 9.04 Jaunty with the latest
libdbd-mysql-perl 4.008-1 which was a pain in the a55 to install and was
only done because doing a CPAN install of DBD::mysql seemed all but
impossible on this server.
And again, this ONLY happens when the application has not made any MySQL
requests for a few hours, or possibly when I restart the MySQL server
but I can't confirm this as consistent.
The "fix" is to hit the server until all the old child processes have
crashed and then new ones are spawned, usually only about six processes,
then everything works fine until the next time.
Tosh
On 11/11/10 4:07 PM, Tuomo Salo wrote:
On Thu, Nov 11, 2010 at 12:58:23AM +0100, Tosh Cooey wrote:
Maybe Apache MPM prefork? How can I tell?
Running httpd with the -l (ell) command line option will print
a list of module names. If you see "prefork.c", you are using
prefork, and if you see "worker.c", you are using the threaded
MPM.
-Tuomo
--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
