Mike Morton said:
> Dan:
>
> Thanks for the suggest.  I will check it out.  The strange thing is that
> as I mentioned, the PHP code that I am using is straightforward, and I
> have never had any problems with the database not disconnecting properly
> with PHP, but that being said, the possibility that it is a db connector
> problem I guess would be OS specific rather than PHP or MYSQL specific
> necessarily?
>
> We will try upgrading PHP to 4.3.4 to see if that helps, and it may be
> also that a MYSQL 4 upgrade is also on the way.
>
> Talking to the host provider, they did mention that the 3 disk array is
> served only by 1 controller, and they will be adding more, perhaps the
> bottleneck is in the disk writes, but I cannot see that being a big
> issue on the relativly low traffic (only around 2GB/month web
> traffic...)
>
> Any other ideas?
>
> On 1/6/04 2:29 PM, "Dan Greene" <[EMAIL PROTECTED]> wrote:
>
>> Is it possible that some portions of your code do not disconnect thier
>> db connections when they are done?  I've seen issues like this with
>> platforms that do not use db pool managers to ensure release of db
>> connections when they are idle for a while.  Particularly if there are
>> error scenerios where the normal connection closure may be skipped...
>>
>> My $0.02...
>>
>> Dan Greene
>>
>>
>>
>>> -----Original Message-----
>>> From: Mike Morton [mailto:[EMAIL PROTECTED]
>>> Sent: Tuesday, January 06, 2004 2:15 PM
>>> To: [EMAIL PROTECTED]
>>> Subject: Sleeping Processes
>>>
>>>
>>> I have a mysql database that is running in conjunction with a
>>> PHP website,
>>> and I am experiencing some significant slowdowns in times of moderate
>>> traffic.
>>>
>>> Now, by moderate, I mean moderate for them, but fairly light
>>> traffic in
>>> terms of actual visitors.
>>>
>>> The library the is causing the slowdowns simple updates a
>>> 'last_active'
>>> variable in a sessions table in mysql which normally has no affect on
>>> loading speed at all, but what I am noticing during this high traffic
>>> period, is anywhere from 50 - 60 processes that are 'sleeping' in the
>>> database when I do a show processlist.  E.g.
>>> +--------+--------+-----------+--------+---------+------+-----
>>> ---------+----
>>> --------------------------------------------------------------
>>> --------+
>>> | Id     | User   | Host      | db     | Command | Time |
>>> State        |
>>> Info
>>>            |
>>> +--------+--------+-----------+--------+---------+------+-----
>>> ---------+----
>>> --------------------------------------------------------------
>>> --------+
>>> | 680849 | tienda | localhost | tienda | Sleep   | 22   |
>>>          |
>>> NULL
>>>            |
>>> | 680859 | tienda | localhost | tienda | Sleep   | 154  |
>>>          |
>>> NULL
>>>            |
>>> | 680878 | tienda | localhost | tienda | Sleep   | 101  |
>>>          |
>>> NULL
>>>            |
>>> | 680942 | tienda | localhost | tienda | Sleep   | 96   |
>>>          |
>>> NULL
>>>            |
>>>
>>>
>>> But upwards of as I said, 50 - 60 of them at any given time.
>>>
>>> I do not have a slow day comparison to offer, but I have done
>>> many a sight
>>> and never seen sleeping processes like this.
>>>
>>> The question is, could these be affecting the slowness of the
>>> database, as I
>>> have determined that it is the database that is slowing down the
>>> site.
>>>
>>> The largest table holds only 42K rows, and the most accessed table is
>>> indexed with the most accessed fields and holds only 16K
>>> rows, so there
>>> should be no problem there.
>>>
>>> The max connections is set to 300, and the version is 3.23.47
>>>
>>> The PHP version is 4.2.3 and I am NOT using mysql_pconnect but rather
>>> mysql_connect:
>>> [EMAIL PROTECTED]("localhost","<blocked>","<blocked>");
>>> @mysql_select_db("tienda");
>>>
>>> Because it is a shared box, I do not have access to make a
>>> lot of changes,
>>> but the company is very co-operative and I am sure would be
>>> helpful for
>>> making small setting changes, as long as we are not talking
>>> major version
>>> updates, as they do have other clients using the server.
>>>
>>> I cannot think of anything else that I can pass on, if anyone has any
>>> suggestions or ideas I would appreciate it as I am plumb out
>>> of them! :)
>>>
>>> TIA
>>>
>>> --
>>> Cheers
>>>
>>> Mike Morton
>>>
>>> ****************************************************
>>> *
>>> * Tel: 905-465-1263
>>> * Email: [EMAIL PROTECTED]
>>> *
>>> ****************************************************
>>>
>>> "Indeed, it would not be an exaggeration to describe the
>>> history of the
>>> computer industry for the past decade as a massive effort to
>>> keep up with
>>> Apple."
>>> - Byte Magazine
>>>
>>> Given infinite time, 100 monkeys could type out the complete works of
>>> Shakespeare. Win 98 source code? Eight monkeys, five minutes.
>>> -- NullGrey
>>>
>>>
>>> --
>>> MySQL General Mailing List
>>> For list archives: http://lists.mysql.com/mysql
>>> To unsubscribe:
>>> http://lists.mysql.com/[EMAIL PROTECTED]
>>>
>>>
>
> --
> Cheers
>
> Mike Morton
>
> ****************************************************
> *
> * Tel: 905-465-1263
> * Email: [EMAIL PROTECTED]
> *
> ****************************************************
>
> "Indeed, it would not be an exaggeration to describe the history of the
> computer industry for the past decade as a massive effort to keep up
> with Apple."
> - Byte Magazine
>
> Given infinite time, 100 monkeys could type out the complete works of
> Shakespeare. Win 98 source code? Eight monkeys, five minutes.
> -- NullGrey
>
>
I have one php application with php and mysql where php is imbedded in the
apache children and when connection pooling is on, there is a connection
for each apache child process.

William R. Mussatto, Senior Systems Engineer
Ph. 909-920-9154 ext. 27
FAX. 909-608-7061



-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to