Thanks again so much for your help. Here is where things stand right now. I tried a lot of different things today, mostly to no avail, and then stumbled on an old MySQL mailing list message that suggested this problem might be related the OS limit on the number of processes a single user can run at one time. So I ran "ulimit -u unlimited" (it had previously been set at 256) and then restarted MySQL. Now it is working fine. Both the number of sleeping/persistent connections and the max_used_connections have gone up well past my earlier 250-251 "ceiling" and I am not seeing any error messages anywhere. I still need to give it a few days, but at the moment I am thinking that somehow, for reasons I don't really understand, raising ulimit -u fixed the problem.
If it didn't, I will probably be back on the mailing list in a couple days. :)
Thanks, Mike
At 02:42 PM 3/31/2003 -0600, Don Read wrote:
On 31-Mar-2003 Mike William wrote: > Hi Don, > > Thanks for the suggestions. Here's what happened. > > > Your pconnects are probably sleeping too long. >> in /etc/my.cnf: >> >>[mysqld] >> set-variable = wait_timeout=10 > > I tried this, and it was a mixed bag. On the one hand, the "Can't create > thread..." error did indeed go away, and max_used_connections and the > number of sleeping/persistent connections dropped down well below > 250. However, making this change caused a new problem: on about every > 50% > of page loads, the following PHP warning would occur: > > Warning: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES) > in > /www/functions.inc on line 66 > > Line 66 of that file is a call to mysql_pconnect(). The MySQL user name > and password hard coded in that file are definitely correct, since the > error is only happening about 50% of the time and no one is modifying > this > file or the grant tables in between. > > Interestingly, nothing gets logged to the MySQL error log when this PHP > warning is generated. I'm not sure whether there are different logging > levels in MySQL and if I need to make my logging more verbose or > something, > but at any rate I can't get any additional information about this error > from the log. > >>If that doesn't take care of it, check your PHP version. Early (~ 2001) >>PHP4 had some buggy pconnect problems. > > I'm using PHP 3.0.18. We have been using the same pconnect() code with > this same version of PHP for years and this problem started happening out > of nowhere only yesterday. > >>Last resort: >>Don't use pconnect unless you really --and I mean *really* need it. >>mysql_connect() is fast enough for just about everything. > > I tried changing all PHP calls to mysql_pconnect() to mysql_connect() > without making any other code changes. Then I restarted MySQL. These > changes had basically no effect, i.e., both max_used_connections and the > number of sleeping/persistent connections both shot right back up to > their > "ceiling" level of ~250. Any thoughts on this? >
Strange ...
Ok, put the pconnects back, and try a 20 second wait_timeout.
The 'ceiling' is 'max_connections' either in one of the my.cnf or as an option in your rc.* scripts.
mysql> show variables like '%connect%';
CHECK TABLES been run ?
What is Apache's MaxRequestsPerChild set at ?
MySQL back_log ?
mysql> show variables like '%back%';
(stabbing wildly in the dark.)
-- Don Read [EMAIL PROTECTED] -- It's always darkest before the dawn. So if you are going to steal the neighbor's newspaper, that's the time to do it. (53kr33t w0rdz: sql table query)
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
