FastCGI and DB connections / global variables?

[Joshua Ruppert]

When I'm using FastCGI do I need to code differently than I do when
using regular CGI? Because the PHP.exe processes don't go away do
global variables stick around from page request to page request,
creating the need for better managment / pooling of DB connections?

Josh

[Chung Leong]

Joshua Ruppert wrote:

When I'm using FastCGI do I need to code differently than I do when
using regular CGI? Because the PHP.exe processes don't go away do
global variables stick around from page request to page request,
creating the need for better managment / pooling of DB connections?

Josh

There is no difference from a programming standpoint. Global variables
are destroyed at the end of each request.

[Joshua Ruppert]

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.

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.
Chung Leong wrote:

Joshua Ruppert wrote:

When I'm using FastCGI do I need to code differently than I do when
using regular CGI? Because the PHP.exe processes don't go away do
global variables stick around from page request to page request,
creating the need for better managment / pooling of DB connections?

Josh

There is no difference from a programming standpoint. Global variables
are destroyed at the end of each request.

[Chung Leong]

Joshua Ruppert wrote:

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.

Hmmm. What's the database server? Maybe a script has left a transaction
open by accident?

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.

Sort off topic, but I think you'll find the kill util in the Windows
Resource Kit quite handy for situations like that.

[Jerry Stuckle]

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.

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.
js*******@attglobal.net
==================

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

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.

Hmmm. What's the database server? Maybe a script has left a transaction
open by accident?

There are four Microsoft SQL Server 2000 servers running behind a
single IIS page server.

As for an open transaction, that was my first thought too. I've
systematically check for and clean up open transactions before each use
and then at the end of each script. I did that because it was easy to
do a global search and replace on the open transaction statements.

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.

Sort off topic, but I think you'll find the kill util in the Windows
Resource Kit quite handy for situations like that.

Thanks for the tip, though do you think FastCGI would respond properly
to a process being killed through the back door like that, and replace
it properly?

[Joshua Ruppert]

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.

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.
js*******@attglobal.net
==================

What do you mean by "top post"? Replying above the previous posts?

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?

[Chung Leong]

Joshua Ruppert wrote:

There are four Microsoft SQL Server 2000 servers running behind a
single IIS page server.

As for an open transaction, that was my first thought too. I've
systematically check for and clean up open transactions before each use
and then at the end of each script. I did that because it was easy to
do a global search and replace on the open transaction statements.

Are you using mssql_pconnect()? Try switching to mssql_connect(). That
would remove the one difference between FastCGI and CGI.

If you're using ADODB through COM, that could be the source of the
problem. PHP (version 4 at least) has a nasty habit of not releasing
COM objects correctly. After a while the leak builds up and the server
sort of dies.

Thanks for the tip, though do you think FastCGI would respond properly
to a process being killed through the back door like that, and replace
it properly?

I think it will. Windows does a decent job cleaning up dead processes.
And to the controlling process, there isn't a huge difference between a
child exiting normally or abnormally.

What you should do though is to not run PHP as a system process. Go
into services and run change the login to IWebUser or something.

[Jerry Stuckle]

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.

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.
js*******@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.
js*******@attglobal.net
==================

[Joshua Ruppert]

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.
js*******@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.
js*******@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.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

There are four Microsoft SQL Server 2000 servers running behind a
single IIS page server.

As for an open transaction, that was my first thought too. I've
systematically check for and clean up open transactions before each use
and then at the end of each script. I did that because it was easy to
do a global search and replace on the open transaction statements.

Are you using mssql_pconnect()? Try switching to mssql_connect(). That
would remove the one difference between FastCGI and CGI.

If you're using ADODB through COM, that could be the source of the
problem. PHP (version 4 at least) has a nasty habit of not releasing
COM objects correctly. After a while the leak builds up and the server
sort of dies.

We're using ODBC instead of the direct MSSQL drivers for one, and we
are using the standard odbc_connect() function. Are there any known
problems using ODBC with MS SQL Server?

Thanks for the tip, though do you think FastCGI would respond properly
to a process being killed through the back door like that, and replace
it properly?

I think it will. Windows does a decent job cleaning up dead processes.
And to the controlling process, there isn't a huge difference between a
child exiting normally or abnormally.

What you should do though is to not run PHP as a system process. Go
into services and run change the login to IWebUser or something.

Wouldn't the service login be the Web Server service login? So to
control the PHP login I would need to change the Web service login?

[Chung Leong]

Joshua Ruppert wrote:

We're using ODBC instead of the direct MSSQL drivers for one, and we
are using the standard odbc_connect() function. Are there any known
problems using ODBC with MS SQL Server?

I'm not too familiar with ODBC. The SQL Server ODBC driver does
connection pooling. With standard CGI you'd get a new connection
everytime, whereas the connection would be reused in FastCGI. As your
application works in CGI but no in FastCGI, that's a good place to
look.

It could also be that you were experiencing deadlocks before, only that
IIS was terminating the process.

I'm sort of out of ideas. You might want to reproduce the condition (on
a test environment of course), then run sp_who/sp_who2 in Query
Analyser to see what is actually happening. It'd also be interesting to
see if the PHP processes would unfreeze if you stop SQLServer.

Wouldn't the service login be the Web Server service login? So to
control the PHP login I would need to change the Web service login?

Nevermind. I mistakenly thought the installer adds PHP as a service.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

We're using ODBC instead of the direct MSSQL drivers for one, and we
are using the standard odbc_connect() function. Are there any known
problems using ODBC with MS SQL Server?

I'm not too familiar with ODBC. The SQL Server ODBC driver does
connection pooling. With standard CGI you'd get a new connection
everytime, whereas the connection would be reused in FastCGI. As your
application works in CGI but no in FastCGI, that's a good place to
look.

It could also be that you were experiencing deadlocks before, only that
IIS was terminating the process.

I'm sort of out of ideas. You might want to reproduce the condition (on
a test environment of course), then run sp_who/sp_who2 in Query
Analyser to see what is actually happening. It'd also be interesting to
see if the PHP processes would unfreeze if you stop SQLServer.

No problem. I'm about at the end of my rope too. I've not been able to
reproduce the problem, but it (stranded PHP processes) actually happens
with or without FastCGI, but without FastCGI I'm able to kill the
stranded processes. So I'm able to keep the site running, my big
problem with FastCGI is that when the !@#$ hit the fan I had to reboot.

We are no strangers to SQL Server and resolving dead locks and
optimizing queries but these stranded processes have been a complete
mystery. The problem is that even if we can prove it's caused by a dead
lock, you can't avoid the occasional dead lock. The best you can do is
write the program so it recovers gracefully. We're thinking about
trying PHP 5 to see if that resolves the problem. We may even write a
low level app to clear out stranded processes. It seem like more of a
bug in PHP forever waiting instead of timing out.

[Jerry Stuckle]

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.
js*******@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.
js*******@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.
js*******@attglobal.net
==================

[Joshua Ruppert]

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.
js*******@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.
js*******@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.
js*******@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.

[Jerry Stuckle]

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.
>>js*******@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.
js*******@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.
js*******@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.
js*******@attglobal.net
==================

[Joshua Ruppert]

Jerry Stuckle wrote:

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.
>js*******@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.
js*******@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.
js*******@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.
js*******@attglobal.net
==================

Ya I guess you are correct, you can't error trap a query that never
returns. I guess my quandry is why the proccesses aren't timing out.
Could I have found a loop hole in the PHP max_execution_time limit?

I'm a little confused about how to troubleshoot this from the DB side.
The only way I see to avoid dead locks is to write all queries without
any joins, or serialize the queries on the database. Is it possible to
serialize some or all queries? I started setting up alerts to create
log entries for deadlock situations, I'm now stumbling through how to
send eMail from SQL Server (that's turned into an entirely new
expedition). Is there any additional you would suggest for
troubleshooting on the db side? Any experience with SQL Server 2000?

[Jerry Stuckle]

Joshua Ruppert wrote:

Jerry Stuckle wrote:

>>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.
>>>>js*******@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.
>>js*******@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.
js*******@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.
js*******@attglobal.net
==================

Ya I guess you are correct, you can't error trap a query that never
returns. I guess my quandry is why the proccesses aren't timing out.
Could I have found a loop hole in the PHP max_execution_time limit?

I'm a little confused about how to troubleshoot this from the DB side.
The only way I see to avoid dead locks is to write all queries without
any joins, or serialize the queries on the database. Is it possible to
serialize some or all queries? I started setting up alerts to create
log entries for deadlock situations, I'm now stumbling through how to
send eMail from SQL Server (that's turned into an entirely new
expedition). Is there any additional you would suggest for
troubleshooting on the db side? Any experience with SQL Server 2000?

Not a hole at all. It's the same as before - PHP can't time out the
script if it's out in a DB call. This could cause memory related to the
call (that the DB needs) to be released and other nasty things. The
same would be true (but to a lesser extent) in some system calls.

Queries don't cause deadlocks. Updates to the database cause deadlocks.
However, those deadlocked updates may hold locks which don't allow
other requests (including locks) to proceed.

Looks like you're going to have to read up on troubleshooting database
problems. There's some good info in the MySQL doc. And I'd suggest you
follow up on a MySQL newsgroup such as comp.databases.mysql.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Chung Leong]

Joshua Ruppert wrote:

I'm a little confused about how to troubleshoot this from the DB side.
The only way I see to avoid dead locks is to write all queries without
any joins, or serialize the queries on the database. Is it possible to
serialize some or all queries? I started setting up alerts to create
log entries for deadlock situations, I'm now stumbling through how to
send eMail from SQL Server (that's turned into an entirely new
expedition). Is there any additional you would suggest for
troubleshooting on the db side? Any experience with SQL Server 2000?

Have you tried the "log long query" option in the ODBC driver? If it
works as stated, it should give you some insight into what is causing
the process to hang.

[Chung Leong]

I was just doing some testing on the SQLServer ODBC driver for
something I was working and I noticed that retrieving rows through the
odbc functions is incredibly slow compare to using the mssql functions.
We're talking about an order of magnitude difference. I wonder if your
script was simply running very slowly and hadn't actually stalled. Try
timing how long it takes to retrieve all rows from a particularly large
table in a couple test scripts, once with ODBC and then with the mssql
functions.

[Joshua Ruppert]

Chung Leong wrote:

I was just doing some testing on the SQLServer ODBC driver for
something I was working and I noticed that retrieving rows through the
odbc functions is incredibly slow compare to using the mssql functions.
We're talking about an order of magnitude difference. I wonder if your
script was simply running very slowly and hadn't actually stalled. Try
timing how long it takes to retrieve all rows from a particularly large
table in a couple test scripts, once with ODBC and then with the mssql
functions.

Thanks for the info. I will look into that and the "long query option".
I really appreciate the tips.

I'm going back and forth with my boss about what could be causing these
stranded processes. We're not sure if the problem comes before or after
the DB connection. The connections that can be viewed from SQL Server
seem to be recycled properly, even if they get into back log is seen of
them. They seem to go away after a maximum of about 10 min.

Conversely when a PHP process is stuck for longer than the max
execution time, I've never seen them be recycled. Though one of our
problems is that we don't know when the PHP processes were started
versus the start of the DB connect. So we don't know how long they have
been sitting, but we have highlighted some of them and waited 15 - 20
min without them going away. Do you know if the process start time
stored anywhere under the hood in Windows?

[Joshua Ruppert]

Joshua Ruppert wrote:

Chung Leong wrote:

I was just doing some testing on the SQLServer ODBC driver for
something I was working and I noticed that retrieving rows through the
odbc functions is incredibly slow compare to using the mssql functions.
We're talking about an order of magnitude difference. I wonder if your
script was simply running very slowly and hadn't actually stalled. Try
timing how long it takes to retrieve all rows from a particularly large
table in a couple test scripts, once with ODBC and then with the mssql
functions.

Thanks for the info. I will look into that and the "long query option".
I really appreciate the tips.

I'm going back and forth with my boss about what could be causing these
stranded processes. We're not sure if the problem comes before or after
the DB connection. The connections that can be viewed from SQL Server
seem to be recycled properly, even if they get into back log is seen of
them. They seem to go away after a maximum of about 10 min.

Conversely when a PHP process is stuck for longer than the max
execution time, I've never seen them be recycled. Though one of our
problems is that we don't know when the PHP processes were started
versus the start of the DB connect. So we don't know how long they have
been sitting, but we have highlighted some of them and waited 15 - 20
min without them going away. Do you know if the process start time
stored anywhere under the hood in Windows?

Wow, well what "..., even if they get into back log is seen of them."
should have said is just "..., even if they get into a backlog
situation."

[Chung Leong]

Joshua Ruppert wrote:

Conversely when a PHP process is stuck for longer than the max
execution time, I've never seen them be recycled. Though one of our
problems is that we don't know when the PHP processes were started
versus the start of the DB connect. So we don't know how long they have
been sitting, but we have highlighted some of them and waited 15 - 20
min without them going away. Do you know if the process start time
stored anywhere under the hood in Windows?

Install ProcessExplorer by Mark Russinovich. It'll get you the info you
need. Here's the link:

http://www.sysinternals.com/Utilitie...sExplorer.html

Right click on the process and select properties. The start time is
near the bottom.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

Conversely when a PHP process is stuck for longer than the max
execution time, I've never seen them be recycled. Though one of our
problems is that we don't know when the PHP processes were started
versus the start of the DB connect. So we don't know how long they have
been sitting, but we have highlighted some of them and waited 15 - 20
min without them going away. Do you know if the process start time
stored anywhere under the hood in Windows?

Install ProcessExplorer by Mark Russinovich. It'll get you the info you
need. Here's the link:

http://www.sysinternals.com/Utilitie...sExplorer.html

Right click on the process and select properties. The start time is
near the bottom.

beautiful, thanks again!

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

Conversely when a PHP process is stuck for longer than the max
execution time, I've never seen them be recycled. Though one of our
problems is that we don't know when the PHP processes were started
versus the start of the DB connect. So we don't know how long they have
been sitting, but we have highlighted some of them and waited 15 - 20
min without them going away. Do you know if the process start time
stored anywhere under the hood in Windows?

Install ProcessExplorer by Mark Russinovich. It'll get you the info you
need. Here's the link:

http://www.sysinternals.com/Utilitie...sExplorer.html

Right click on the process and select properties. The start time is
near the bottom.

Ok now I'm really confused. Yesturday I found some more stranded
processes (we usually get at least a few every few days). When I loaded
up the Process Explorer the properly running PHP processes were all
listed under w3wp.exe, which I'm assuming is the IIS worker process.
The processes that were stalled were all at the base level where you
would see the System Idle Process and Explorer. I'm not sure what this
means.

Could it mean that they are being triggered by something outside of
IIS?

Are the processes not imediately associated to IIS? (If that is true
then it seems that the processes are failing very early in their
execution.)

[Chung Leong]

Joshua Ruppert wrote:

Ok now I'm really confused. Yesturday I found some more stranded
processes (we usually get at least a few every few days). When I loaded
up the Process Explorer the properly running PHP processes were all
listed under w3wp.exe, which I'm assuming is the IIS worker process.
The processes that were stalled were all at the base level where you
would see the System Idle Process and Explorer. I'm not sure what this
means.

No, the stalled processes are just "orphaned." The worker process that
had spawn them earlier has exited, leaving them without a parent. The
program shows my firefox.exe process in the same state, because the
Windows shell had crashed earlier.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

Ok now I'm really confused. Yesturday I found some more stranded
processes (we usually get at least a few every few days). When I loaded
up the Process Explorer the properly running PHP processes were all
listed under w3wp.exe, which I'm assuming is the IIS worker process.
The processes that were stalled were all at the base level where you
would see the System Idle Process and Explorer. I'm not sure what this
means.

No, the stalled processes are just "orphaned." The worker process that
had spawn them earlier has exited, leaving them without a parent. The
program shows my firefox.exe process in the same state, because the
Windows shell had crashed earlier.

But wouldn't that mean that IIS worker had crashed? Do you think IIS
would be able to restart the worker process if it crahes? When I
observed the orphaned processes I still had a working IIS worker
process.

[Chung Leong]

Joshua Ruppert wrote:

But wouldn't that mean that IIS worker had crashed? Do you think IIS
would be able to restart the worker process if it crahes? When I
observed the orphaned processes I still had a working IIS worker
process.

No, I was just using that as an example. A process doesn't have to wait
for the termination of its children before exiting normally.

I don't know the internals of IIS. It's a fairly typical practice
though in server applications to respawn workers every now and then.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

But wouldn't that mean that IIS worker had crashed? Do you think IIS
would be able to restart the worker process if it crahes? When I
observed the orphaned processes I still had a working IIS worker
process.

No, I was just using that as an example. A process doesn't have to wait
for the termination of its children before exiting normally.

I don't know the internals of IIS. It's a fairly typical practice
though in server applications to respawn workers every now and then.

It seems like I might be back to having a monitoring process to look
for orphaned processes. One detail I may not have included in our
discussion so far is that the orphanded processes are always lower in
memory usage (~100K - ~6,000K) than properly working processes
(~10,000K - ~14,000K). This tells me that it's probably failing before
it even gets to the db connection. Does that make sense?

[Chung Leong]

Joshua Ruppert wrote:

It seems like I might be back to having a monitoring process to look
for orphaned processes. One detail I may not have included in our
discussion so far is that the orphanded processes are always lower in
memory usage (~100K - ~6,000K) than properly working processes
(~10,000K - ~14,000K). This tells me that it's probably failing before
it even gets to the db connection. Does that make sense?

I wouldn't read too much into it. Memory management in Windows is quite
complex. I believe the memory usage reported in task manager is the
physical amount. A process that has stalled will have a smaller foot
print since the OS would divert memory previously allocated to it to
other processes.

You can figure out where the process is stalling through Process
Explorer. Go to properties then threads, select the php.exe thread and
press the stack button. The item at the bottom is the last function
called across a DLL. Somewhere in the chain you might see a function
name SQLxxxxxx. That'd be a function in the ODBC driver.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

It seems like I might be back to having a monitoring process to look
for orphaned processes. One detail I may not have included in our
discussion so far is that the orphanded processes are always lower in
memory usage (~100K - ~6,000K) than properly working processes
(~10,000K - ~14,000K). This tells me that it's probably failing before
it even gets to the db connection. Does that make sense?

I wouldn't read too much into it. Memory management in Windows is quite
complex. I believe the memory usage reported in task manager is the
physical amount. A process that has stalled will have a smaller foot
print since the OS would divert memory previously allocated to it to
other processes.

You can figure out where the process is stalling through Process
Explorer. Go to properties then threads, select the php.exe thread and
press the stack button. The item at the bottom is the last function
called across a DLL. Somewhere in the chain you might see a function
name SQLxxxxxx. That'd be a function in the ODBC driver.

Hey, we may actually be getting somewhere here. Thanks again.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

It seems like I might be back to having a monitoring process to look
for orphaned processes. One detail I may not have included in our
discussion so far is that the orphanded processes are always lower in
memory usage (~100K - ~6,000K) than properly working processes
(~10,000K - ~14,000K). This tells me that it's probably failing before
it even gets to the db connection. Does that make sense?

I wouldn't read too much into it. Memory management in Windows is quite
complex. I believe the memory usage reported in task manager is the
physical amount. A process that has stalled will have a smaller foot
print since the OS would divert memory previously allocated to it to
other processes.

You can figure out where the process is stalling through Process
Explorer. Go to properties then threads, select the php.exe thread and
press the stack button. The item at the bottom is the last function
called across a DLL. Somewhere in the chain you might see a function
name SQLxxxxxx. That'd be a function in the ODBC driver.

Ok, It took a little while but I currently have one orphaned process
and it has just one thread and it seems to still be in the
initialization phase of the base PHP environment. The thread is labeled
as php.exe!OS_SetFlags+0xa0. The stack for the thread looks like this:
ntkrnlpa.exe+0x8cf3e
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x32cee
ntkrnlpa.exe+0x32f95
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x137e4c
ntkrnlpa.exe+0x88c6c
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
php4ts.dll!zend_timeout+0xac
php.exe+0x1e90
php.exe!OS_SetFlags+0x183
kernel32.dll!IsProcessorFeaturePresent+0x9e

Any thoughts?

[Chung Leong]

Joshua Ruppert wrote:

Ok, It took a little while but I currently have one orphaned process
and it has just one thread and it seems to still be in the
initialization phase of the base PHP environment. The thread is labeled
as php.exe!OS_SetFlags+0xa0. The stack for the thread looks like this:
ntkrnlpa.exe+0x8cf3e
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x32cee
ntkrnlpa.exe+0x32f95
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x137e4c
ntkrnlpa.exe+0x88c6c
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
php4ts.dll!zend_timeout+0xac
php.exe+0x1e90
php.exe!OS_SetFlags+0x183
kernel32.dll!IsProcessorFeaturePresent+0x9e

Any thoughts?

Hmmm... The script is definitely timing out. PHP is just having trouble
exiting out cleanly. zend_timeout() does one of two things: it either
calls exit() to terminate the process immediately, or it does a
longjmp() to a bailout point set earlier. Usually it's the latter.
Whatever it's doing it's fubar...

One thing to try is set time limit to 0 (i.e. infinite). At least then
PHP wouldn't fall into this trap.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

Ok, It took a little while but I currently have one orphaned process
and it has just one thread and it seems to still be in the
initialization phase of the base PHP environment. The thread is labeled
as php.exe!OS_SetFlags+0xa0. The stack for the thread looks like this:
ntkrnlpa.exe+0x8cf3e
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x32cee
ntkrnlpa.exe+0x32f95
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x137e4c
ntkrnlpa.exe+0x88c6c
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
php4ts.dll!zend_timeout+0xac
php.exe+0x1e90
php.exe!OS_SetFlags+0x183
kernel32.dll!IsProcessorFeaturePresent+0x9e

Any thoughts?

Hmmm... The script is definitely timing out. PHP is just having trouble
exiting out cleanly. zend_timeout() does one of two things: it either
calls exit() to terminate the process immediately, or it does a
longjmp() to a bailout point set earlier. Usually it's the latter.
Whatever it's doing it's fubar...

One thing to try is set time limit to 0 (i.e. infinite). At least then
PHP wouldn't fall into this trap.

Are you refering to the max execution time?

[Chung Leong]

Joshua Ruppert wrote:

Chung Leong wrote:

Joshua Ruppert wrote:

Ok, It took a little while but I currently have one orphaned process
and it has just one thread and it seems to still be in the
initialization phase of the base PHP environment. The thread is labeled
as php.exe!OS_SetFlags+0xa0. The stack for the thread looks like this:
ntkrnlpa.exe+0x8cf3e
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x32cee
ntkrnlpa.exe+0x32f95
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x137e4c
ntkrnlpa.exe+0x88c6c
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
php4ts.dll!zend_timeout+0xac
php.exe+0x1e90
php.exe!OS_SetFlags+0x183
kernel32.dll!IsProcessorFeaturePresent+0x9e
>
Any thoughts?

Hmmm... The script is definitely timing out. PHP is just having trouble
exiting out cleanly. zend_timeout() does one of two things: it either
calls exit() to terminate the process immediately, or it does a
longjmp() to a bailout point set earlier. Usually it's the latter.
Whatever it's doing it's fubar...

One thing to try is set time limit to 0 (i.e. infinite). At least then
PHP wouldn't fall into this trap.

Are you refering to the max execution time?

Yes.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

Chung Leong wrote:

Joshua Ruppert wrote:
Ok, It took a little while but I currently have one orphaned process
and it has just one thread and it seems to still be in the
initialization phase of the base PHP environment. The thread is labeled
as php.exe!OS_SetFlags+0xa0. The stack for the thread looks like this:
ntkrnlpa.exe+0x8cf3e
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x32cee
ntkrnlpa.exe+0x32f95
ntkrnlpa.exe+0x2927a
ntkrnlpa.exe+0x137e4c
ntkrnlpa.exe+0x88c6c
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject+0x12
php4ts.dll!zend_timeout+0xac
php.exe+0x1e90
php.exe!OS_SetFlags+0x183
kernel32.dll!IsProcessorFeaturePresent+0x9e

Any thoughts?
>
Hmmm... The script is definitely timing out. PHP is just having trouble
exiting out cleanly. zend_timeout() does one of two things: it either
calls exit() to terminate the process immediately, or it does a
longjmp() to a bailout point set earlier. Usually it's the latter.
Whatever it's doing it's fubar...
>
One thing to try is set time limit to 0 (i.e. infinite). At least then
PHP wouldn't fall into this trap.

Are you refering to the max execution time?

Yes.

Ok thanks. I'll see if that changes anything. We're also switching over
to a setup with twice the horsepower, to mitigate the possibility of a
resource limitation creating the problem. Thanks again for all your
help.

[Chung Leong]

Joshua Ruppert wrote:

Ok thanks. I'll see if that changes anything. We're also switching over
to a setup with twice the horsepower, to mitigate the possibility of a
resource limitation creating the problem. Thanks again for all your
help.

You didn't mention what version of PHP you're using. If you're on 4.3,
try 4.4. I have noticed that 4.3 has some issues with COM clean-up,
with objects getting blown away prematurely. I think the SQL Server
ODBC uses OLE-DB underneath, so bad things could happen when the
objects it's using sudden become invalid.

[Joshua Ruppert]

Chung Leong wrote:

Joshua Ruppert wrote:

Ok thanks. I'll see if that changes anything. We're also switching over
to a setup with twice the horsepower, to mitigate the possibility of a
resource limitation creating the problem. Thanks again for all your
help.

You didn't mention what version of PHP you're using. If you're on 4.3,
try 4.4. I have noticed that 4.3 has some issues with COM clean-up,
with objects getting blown away prematurely. I think the SQL Server
ODBC uses OLE-DB underneath, so bad things could happen when the
objects it's using sudden become invalid.

We're running 4.3.10 so I'll try that too, thanks