Zend Enabler error Error: Could not locate a free PHP proces

[ahmadrajab]

My friend is facing a similar situation, But I dont think he can seem to fix the problem, like printpac there, the php process seems to be using up all its memory and the server is starting to crash

[cricketzend]

Ido, can this be a problem if/when the php script sets a timeout (and runs longer) which is larger than the timeout in the zend enabler conf? We've correlated these issues with long-running SOAP calls or MSSQL DB connectivity issues.

We continue to have this issue and are having to restart apache on a regular basis across all of our servers.

[cricketzend]

I was able to create a scenario to reproduce this. Maybe this will help find a solution.

In ZendEnablerConf.xml set the connection timeout to 5 seconds and the request timeout to 10 seconds (<Timeouts connectionTimeout="5" requestTimeout="10" />). Set it to only startup 1 process (<ProcessCount start="1" extra="1"/>). In the php.ini set the execution time to 30 seconds.
create a php script that does the following:
1. sleep(8) // wait for 8 seconds
2. create a soap call (or MSSQL db call) that will take longer than 2 seconds.
3. open a browser and reload your test page 5-10 times quickly, not waiting for them to complete/timeout.

In our case, this represents a valid production scenario. We have SOAP requests that can take 2-3 minutes at times so we use php's set_time_limit() to increase the timeout on the fly before we make the SOAP request. I believe this is conflicting with Zend Enabler's request timeout setting, which causes the timeout and the apache php process to hang up.

[idobms]

You are describing an interesting scenario. Thanks for sharing the information. We will need to run it in our lab and see what the fast cgi processes are doing when the long call returns and if the fact that the request timeout was reached before causes the process to wait.

Did you find any correlation between this issue and the enabler “Error: Process terminated right after start". Status -1073741502 is a STATUS_DLL_INIT_FAILED (0xC0000142) error. One of the symptoms of memory heap exhaustion is a STATUS_DLL_INIT_FAILED in user32.dll when a new process starts. It might be that after some time a few processes are hung which will cause apache to launch more fast cgi processes and reach the desktop heap limit.

Ido

[cricketzend]

Ido, when we did the live sessions with you and Nick, we monitored the desktop heap usage and it didnt seem to change at all when we observed the server issues. That was a while ago and we have not monitored it recently. From what I remember, the php soap DLL and sql server DLL was not working well with long running processes (or large payload request/responses). I thought your team was looking into the dll's for 64bit o/s and determining if they were causing the problem.

[idobms]

I believe that the issue with the soap dll was causing a crash in fastcgi and was addressed a while ago. This scenario of getting the fast cgi not to exit after long transactions seems to be different. We will try to replicate the scenario you provided and understand what is the process waiting on in order to exit properly.

[idobms]

The occasional apache processes hang related to the timeouts scenario should be fixed in Zend Server 5.6. Thanks for the detailed description of the problem.