Huge lsphp5 problem

[muiruri]

I'm having a big problem with lsphp5.

Every few hours, dozens of lsphp5 processes accumulate without closing for sometime, which make server load jump over the roof (200 - 350 CPU load!).

This began on our Cpanel server, after we upgraded both LSWS to latatest 4.0.12 plus PHP latest 5.2.x series PHP 5.2.12

We've downgraded LSWS back to 4.0.11, but problem is not yet completely gone, only takes longer to show up.

We're using eaccelerator which we've set to use /dev/shm/eaccelerator

On LSWS settings We're also using;

Configuration -> Server - Cache;

with following settings;

Storage Path /backup/cache (using indepedent drive to minimize i/o on web server)
Max Object Size - 1024000
Cache Expire Time (seconds) - 120 secs

Configuration -> Server - External App;

with following settings;

Environment;
PHP_LSAPI_MAX_REQUESTS=50000
PHP_LSAPI_CHILDREN=100
LSAPI_MAX_IDLE_CHILDREN=60

Max Connections - 100
Instances - 1
Initial Request Timeout (secs) - 60
Persistent Connection - No
Connection Keepalive Timeout - 60
Max Idle Time - 3

We've to manually SSH into the server & do command;

killall lsphp5

to stop the crazy overload.

We have high traffic sites on the server, & all has been working perfectly well until 5 days ago when we did the two upgrades above.

Is this a compatibility issue between PHP 5.2.12 & eAccelerator?

George also suggests to check opcode cache on the server, what does this mean?

Or how do we check other opcode cache on the server?

Finally what is lshttpd process? Is it connected to lsphp5? Is it also supposed to close after a short time? We've noticed it showing as well along side the lsphp5, although it's only one process.

Please help? This is causing downtimes to the sites every day!

[mistwang]

Yes, there are compatibility issue between PHP 5.2.12 and eAccelerator. either stop eAccelerator or downgrade PHP. it will fix the problem.
eAccelerator is the opcode cache in your setup.

[muiruri]

What version of PHP works best with eAccelerator? Would PHP 5.2.11 work perfectly well?

Does eAccelerator help complement the Cache feature of LSWS? Or does each cache different things?

[mistwang]

5.2.11 works well with eAccelerator I think, you may need to try the older stable eAccelerator version.

[muiruri]

Disabled eAccelerator last night & everything looks good now, I have also switched back LSWS to lastest 4.0.12, therefore now seems to work well also with latest PHP 5.2.11

Being a cpanel server, trouble is from WHM, software update menu option for easyapache, only version available for eAccelerator is Release-0.9.6-rc1

This means installing latest stable Release-0.9.5.3 would need manually installed. Challenge would be what happens when cpanel updates run or next time I use easyapache I think the eAccelerator lines I manually add in php.ini will be wiped out.

Please clarify on each of the following;

(a) If we're already using or enabled the cache feature in LSWS, does eAccelerator make any difference?

(b) In general LSWS speeds up PHP on the server by 4-5 times as per LS website, therefore why would one need eAccelerator? Does it do something LSWS is not doing?

(c) Finally one more question is, although we disabled the Release-0.9.6-rc1 eAccelerator from all our servers, which all have latest PHP 5.2.12, how come this problem is lsphp5 causing overload was only on the one server? Difference is the server with the trouble has the most high traffic sites, while other servers standard traffic. Does this mean the problem between PHP 5.2.12 & eAccelerator latest release is visible mainly on servers with high traffic?

[mistwang]

cache feature in LSWS has nothing to do with PHP, it is page change like apache mod_cache.

opcode cache makes PHP itself run faster, it is on top of the speed you gain from LSWS, it is better to have.

Yeah, that problem between PHP 5.2.12 and eAccelerator starts to surface when server load is high.

[jrmarino]

Chalk me up with the people with problems with LSAPI 5.1.

I recompiled PHP 5.2.8 (a version that has worked well with LSAPI 4.8) on my 3.3.23 LSWS (solaris 10). phpinfo shows fine, but all of a sudden I started receiving cron job output -- core dumps on lsphp due to segfaults. These are command line scripts, not called through LSWS.

I recompiled 5.2.8 with LSAPI 4.10 and the segfaults/core dumps went away.

I guess I'll stick with the 4 series until LSAPI 5 has a lot more testing on it.
FYI, I have the last 420MB core dump, but I don't think gdb is install on this machine...

[anewday]

Using lsapi 5.1 with php 4.4.9 and eaccelerator for over 5 days now. No problems so far. Does it only affect php 5?

[mistwang]

Yes, it affect PHP 5 only.

[jrmarino]

Originally Posted by jrmarino

Chalk me up with the people with problems with LSAPI 5.1.

I recompiled PHP 5.2.8 (a version that has worked well with LSAPI 4.8) on my 3.3.23 LSWS (solaris 10). phpinfo shows fine, but all of a sudden I started receiving cron job output -- core dumps on lsphp due to segfaults. These are command line scripts, not called through LSWS, and it happens on both versions of the OS (and two types of CPU, the solaris 10 is on AMD64 and the opensolaris is on i386)

I recompiled 5.2.8 with LSAPI 4.10 and the segfaults/core dumps went away.

I guess I'll stick with the 4 series until LSAPI 5 has a lot more testing on it.
FYI, I have the last 420MB core dump, but I don't think gdb is install on this machine...

Follow up:
I rebuilt php 5.2.12 with LSAPI 5.2 using GCC 4.4.3 on solaris 10 and openSolaris Nevada 130 and used it with LSWS 3.3.23.

It works fine with LSWS, but it still segfaults and core dumps with my CLI scripts as mentioned before. This does not happen with LSAPI 4.10.

So LSAPI 5.2 still causes problems. Personally I'm staying with 4.10 for a while.