enable_phpa.sh fails

matt

Active Member
#1
I've tracked it down to the line with "uname -p", which returns:

Code:
Try `uname --help' for more information.
uname -a returns:

Code:
Linux web2.wordpress.com 2.6.12-9-amd64-k8-smp #1 SMP Mon Oct 10 13:18:18 BST 2005 x86_64 GNU/Linux
uname -m seems to return what you want, but obviously the x86_64 value fails later in the script.
 

mistwang

LiteSpeed Staff
#2
Thank you for the bug report. We will fix this bug in next release.

You have to build the opcode cache binary by yourself, as we don't build AMD64 binaries, and it is hard to tell whether 32Bits or 64Bits binary is required in the shell script, as either verion of PHP binary can be used on the 64 bits linux. Just a reminder. :)
 

matt

Active Member
#3
Okay. You may want to consider 64-bit binaries as the new Xeons (EMT64) and all Opterons are compatible with the amd64 "stuff." (I don't know the technical term.)
 

ts77

Well-Known Member
#4
I'd recommend to use APC from PECL as php-cache.
It has made great enhancements in the last months and can only be better than the unmaintained phpa.
 

mistwang

LiteSpeed Staff
#5
Matt,
For web server kind of application, 32bits binary on 64bits OS usually gives better performance than 64Bits binary. :)

Thomas,
Be careful with APC, 3.0.8 crashes PHP process after running for a while, forunately, LSWS can restart PHP automatically when it happens. :)
eAccelerator probably is the best choice now.
 

ts77

Well-Known Member
#6
The point with "apc 3.0.8 crashes php", is it with:
FATAL: erealloc(): Unable to allocate 15360 bytes
FATAL: erealloc(): Unable to allocate 61440 bytes
FATAL: erealloc(): Unable to allocate 245760 bytes
FATAL: erealloc(): Unable to allocate 245760 bytes
FATAL: emalloc(): Unable to allocate 3840 bytes
FATAL: emalloc(): Unable to allocate 27870 bytes

? ;)

I'm currently trying 3.0.8 while 3.0.6 had run for some time without problems and with one app I see those errors, until I remove apc ;).

I was searching the web for quite some time and I don't see this error for apc mentioned.
Are you sure it could not be lsws related? I've rised the memory limits higher and higher for that external application but that didn't help.

Any ideas?


thx,

thomas
 

mistwang

LiteSpeed Staff
#7
Are you sure it could not be lsws related?
I am pretty sure. you can set memory limit to "0" to use the system's default.

Is it possible that the erealloc() failure is for shared memory? I think it is different from heap and configurable via kernel configuration, the default is like 20M or 30M, I am not exactly sure.

As I know, when it happens, it will crash the whole group of PHP process, even the a fresh PHP process forked. I guess there are memory leak in apc's shared memory allocation.
 

ts77

Well-Known Member
#8
George,

thanks for your reply.
I'll try to do some more debugging on the dev-server with apc.

I hope that I can ask the apc-devs in the end to get a solution :).
 
Top