PHP - 503 error

[sofatime]

Hi,

I have problems with PHP on a new installation: Sometimes lsws cannot process PHP requests and answers with "503 Service Unavailable". I then need to restart lsws to recover from the error. This only happens rarely and I don't see a pattern or a direct cause. Any hints on how I can find the reason?

information about the installation:
lsws 3.1.1, PHP 5.2.2, compiled with LSAPI 4.0, APC 3.0.14
Solaris 10 x86
I am using devpoll, because that proved better on Solaris on another installation.

In the error log I get the following:
Connection idle time: 301 while in state: 5 watching for event: 25,close!
HttpExtConnector state: 8, request body sent: 1959, response body size: 0, response body sent:0, left in buffer: 0, attempts: 0.
ExtConn timed out while processing.

I use one parent instance of lsphp with 20 child processes.

I suppose something is wrong with my lsphp. The same lsphp works on another machine without problems. I tried to have exactly the same versions of all needed libraries (like gd, curl), but I am not sure if I got them all. So my next question is: How can I compile PHP with as few dependencies as possible, i.e. the same as the stock php of lsws? With curl and gd and all the others statically compiled in php.

Thanks for help!
Daniel

[mistwang]

You can try increasing PHP's memory limit, it might help if your problem is that PHP needs more memory to process the request.
There might be memory leak in PHP, so set "PHP_MAX_REQUESTS" to a lower value might help.

You can rebuild the PHP binary with any modules you want.

[sofatime]

Thanks for the information. I have already increased PHPs memory limit to 128MB and in lsws ext app and the lsphp connector to 200MB. I will also try with PHP_MAX_REQUESTS.

About building the PHP binary: I already built the PHP binary with the modules I need, but when I move the binary to another system I also have to have all the necessary libraries on the new system (gd, curl, zlib, libxml and all that stuff). With the lsphp shipped with lsws that is not necessary (tested with ldd). So I assume that you have somehow compiled those libraries statically in lsphp. How did you do that?

Daniel

[mistwang]

Yeah, our PHP binary is statically linked. You can take a look at our configuration parameters, we do not use library files under the system directory, but create our own copy, and only make the static library .a available for linking.

[sofatime]

Ah, that's the way it works! I will try that. Thanks a lot.

[sofatime]

I tried with LSAPI_MAX_REQUESTS=10 as a test (will use 1000 later) but the lsphp processes were not stopped after 10 requests. I then tried with PHP_LSAPI_MAX_REQUESTS=10, now it worked. According to the manual both LSAPI_MAX_REQUESTS and PHP_LSAPI_MAX_REQUESTS should work. Is this not correct? Or is PHP_MAX_REQUESTS correct as you write in your post?
I am using LSAPI 4.0.

[mistwang]

It should be LSAPI_MAX_REQS instead of LSAPI_MAX_REQUESTS, the document will be fixed.
Thanks.

[sofatime]

BTW: The 503 problem was solved by disabling APC. Using LSAPI_MAX_REQS did not help, so apparently it was not a memory leak. Now the server works very well, although we see quite a bit higher load because of the missing APC. I will try APC again when a new version comes out. (strange thing is the same setup with APC works perfectly on another machine)

[mistwang]

You can also try eAccelerator or XCache.