|
|
Posted by Jerry Stuckle on 07/28/06 20:51
Joshua Ruppert wrote:
> Jerry Stuckle wrote:
>
>>Joshua Ruppert wrote:
>>
>>>Jerry Stuckle wrote:
>>>
>>>
>>>>Joshua Ruppert wrote:
>>>>
>>>>
>>>>>Jerry Stuckle wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Joshua Ruppert wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>With that said I'm not sure what my problem is. I have a website that
>>>>>>>has already been developed running Win2K and PHP 4, that I tried to
>>>>>>>switch over to FastCGI. When I did this every thing ran fine for a
>>>>>>>while, until we had a spike in traffic. (Since FastCGI was tried we
>>>>>>>have moved to Win2K3.)
>>>>>>>
>>>>>>>The root cause of the problems seems to be the response time of the DB
>>>>>>>servers but I'm not certain. When the database servers became loaded,
>>>>>>>the PHP processes seemed to hang while waiting for the database to
>>>>>>>respond. Eventually this effected each of the PHP processes started by
>>>>>>>FastCGI, completely taking down the site.
>>>>>>>
>>>
>>>t> >>>The only way I found to restart the PHP processes is to reboot
>>>the
>>>
>>>
>>>>>>>machine, because task manager did let me kill the processes that were
>>>>>>>started by FastCGI.
>>>>>>>
>>>>>>>Is there anything that you could see (slow DB connections or otherwise)
>>>>>>>that would cause this kind of behavior?
>>>>>>>
>>>>>>>I used the PHPLens.com EasyWindows PHP Installer, but I'm having
>>>>>>>trouble finding resources to help me fine tune FastCGI opperation.
>>>>>>>
>>>>>>>Any suggestions are greatly appreciated.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>Is it possible you're getting into a deadlock situation? These are more
>>>>>>likely to show up when the database is busy, and you probably wouldn't
>>>>>>be able to cancel the task.
>>>>>>
>>>>>>P.S. - please don't top post. Thanks.
>>>>>>
>>>>>>--
>>>>>>==================
>>>>>>Remove the "x" from my email address
>>>>>>Jerry Stuckle
>>>>>>JDS Computer Training Corp.
>>>>>>jstucklex@attglobal.net
>>>>>>==================
>>>>>
>>>>>
>>>>>What do you mean by "top post"? Replying above the previous posts?
>>>>>
>>>>
>>>>Yep. This is perfect. Thanks!
>>>>
>>>>
>>>>
>>>>>No, I have not observed a deadlock. The site is 99% read only, so that
>>>>>greatly reduces the risk also. Isn't FastCGI suppose to clean up dead
>>>>>processes?
>>>>>
>>>>
>>>>
>>>>OK, are you sure you're closing your connections at the end of the
>>>>script? Waiting for PHP's gc to do it may take a little time.
>>>>
>>>>--
>>>>==================
>>>>Remove the "x" from my email address
>>>>Jerry Stuckle
>>>>JDS Computer Training Corp.
>>>>jstucklex@attglobal.net
>>>>==================
>>>
>>>
>>>Yes, I went through the scripts very methodically and systematically to
>>>add the following to the end of each script
>>>odbc_close($connect);
>>>
>>>and I also do a
>>>odbc_free_result($result);
>>>
>>>before each
>>>$result = odbc_exec($connect, $query);
>>>
>>>This was my first website to use PHP and so I had to go back and
>>>retrofit it to do DB resource cleanup. I performed a search and replace
>>>on the odbc_exec calls to add the odbc_free_result call before each.
>>>The only thing I'm seeing as I write this is that I could do a
>>>odbc_free_result call before each odbc_close, but I would assume that a
>>>close would also free the result set.
>>>
>>
>>I always free my results as soon as I'm done with them, and close the
>>database when I've completed processing with it. I guess I've been
>>bitten too many times in almost 40 years of programming to depend on the
>>gc :-).
>>
>>FastCGI will clean up dead processes when the gc runs. The problem is
>>it doesn't run immediately - there can be (and generally is) a delay
>>before it cleans everything up. But like you, I would expect closing
>>the connection would free the results, at least as far as the database
>>end goes. And even if they weren't cleaned up on the PHP end
>>immediately, they shouldn't affect other connections.
>>
>>Could it be the database servers are just so loaded they can't get back
>>in a reasonable time? I've found typically response time is an
>>exponential curve - going from 1% load to 10% load won't affect response
>>time much - but going from 90% to 99% load has a very big effect. Load
>>could include CPU, disk, network, etc.
>>
>>
>>--
>>==================
>>Remove the "x" from my email address
>>Jerry Stuckle
>>JDS Computer Training Corp.
>>jstucklex@attglobal.net
>>==================
>
>
> Ya, I've come a long way since the initial creation of this site but I
> believe that it's pretty tight now, when it comes to db connection
> cleanup.
>
> The load on the DB servers was our first thought too, but to complicate
> my research even more, I've seen the stranded processes even durring
> low traffic times. This makes absolutely no sense to me and seems to
> point to a dead lock issue, but then we're back to the PHP libraries
> not handling dead locks gracefully. Which I don't think I can do much
> about, asside from having a separate app to monitor stranded processes.
>
But deadlocks handling isn't a function of the PHP libraries - it's one
of the database. It would, for instance, be very cruel to pull the
calling program (and it's memory) out from under the DB in the middle of
a DB call. Which, BTW, is possibly why you can't cancel the tasks from
the OS.
I suspect if you recycle the database things would free up (with errors,
of course).
Sounds to me like maybe you need to troubleshoot this from the db end.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|