eAccelerator and LSPHP ?

[wanah]

Hello,

Having had alot of problems with xCache that I believe to be related to a problem with php processes being killed that have a large amount of shared memory and litespeed's implementation of php suexec deamon mode, I'm looking for an alternative.

eAccelerator has two types of cache, shm memory cache and disk based cache.

If I were to set the shm memory cache to 8GB and disable disk cache (concidering my kernel allows up to 64GB shared memory would I run into the same problems as xCache ?

sysctl -a | grep shmmax
kernel.shmmax = 68719476736

If so, although this is not optimum as eAccelerator would be copying from shm memory to tmpfs memory disk would it be better to have maybe 256MB shm and 8GB ramdisk to try and avoid the shared memory issues ?

Thanks

 

[NiteWave]

I'd recommend:
use disk cache, not use shared memory, or use minimum shared memory -- 1M only. not sure if it's possible to completely disable shared memory in latest eAccelerator. per my past experience with eAccelerator, 1M is the minimum shared memory size and you have to set it.

no need set up an additional ram disk like following:
tmpfs /lsgzip tmpfs rw,uid=99,gid=32016,size=8G,nr_inodes=10k,mode=0770 0 0

just use /dev/shm, it's ram disk already created from you by linux.
if you have 256G memory, your /dev/shm may be allocated 128G. check it by:
#df -h

create a sub folder under /dev/shm, say /dev/shm/eaccelarator, set eAccelerator's disk cache location to it. so eAccelerator actually store opcache in memory.

 

[wanah]

Does this mean that php suexec deamon mode is not very compatible with php modules that use shm memory ?

 

[NiteWave]

I don't think so.

php suexec deamon mode comes out for better utilizing shared memory. it works quite well in many servers so far so long. but it may have problem in some cases -- but you have to submit a bug report accurately. you can't draw such a big conclusion --- "php suexec deamon mode is not very compatible with php modules that use shm memory". it may due to xcache's issue, or simply xcache's config issue, or php internal bug, or really due to litespeed's php suexec daemon mode. to identify the issue, need reproduce the issue reliably first. just like other software/hardware bugs.

 

[wanah]

I was just asking, not submitting a bug report

I will try getting eaccelerator working, I see that you have recently recommended eaccelerator when using suexec mode and also pointing out that maybe my xcache install was actually never saving any CPU beacuse of frequent process changes.

I've now got my hopes up for eaccelerator with shm reduced to 1MB, hopefully it writes to (ram) disk directly when the 1MB are full so all the cache doesn't get spoilt when the process changes

 

[NiteWave]

it's worth to try eAccelerator with php suExec daemon.

I see that you have recently recommended eaccelerator when using suexec mode and also pointing out that maybe my xcache install was actually never saving any CPU beacuse of frequent process changes.

to clarify: this is not accurate. I think due to not communicate/discuss enough.
if we've ever recommended, then that's for suExec non-daemon mode, not daemon mode.

for shared hosting(running cPanel is the largest one), nearly 100% users are running php in non-daemon mode. in this case, all ISP or host recommend to use eAccelerator, no host or cPanel recommend to use xcache or APC, since the php process's life cycle is short.

php suExec daemon mode is unique from litespeed, which target is just to make use of XCache/APC in shared host, just opposite to your expression.

 

[wanah]

So with suexec in deamon mode should I give eaccelerator some shm cache or not ?

If php is run with suexec deamon mode is designed to play well with shared memory then why should I disable shm in eaccelerator ?

Thanks

 

[NiteWave]

eAccelerator cache opcode on disk is unique and not exist in APC or XCache.

if use shared memory to store opcode code, it's widely known that APC or XCache is better than eAccelerator.

so if you want to try disk cache, try eAccelerator;
for shared memory opcode cache, try APC or XCache. especially with php suExec daemon mode, XCache looks better than APC.

if XCache/APC works well with php suExec daemon mode, please go XCache/APC -- in fact I'm managing a few physical servers, run php suExec daemon mode, and simply run APC, they've been working fine for months.

since you said in your case, XCache not working well with php suExec daemon, and suspect shared memory has been the problem, so I suggest you try disk based opcode -- at present only eAccelerator is available.

 

[Monarobase]

With xCache I had problems with large shared memory usage and php crashing and APC is not secure on shared hosting because of its object cache being accessible to all users on the server.

I want to allow multiple GB of cache because this server will have between 600 and 800 sites on it and xCache don't seem to like large environements and to be only optimised for small servers with low to medium amounts of cache.

 

[mistwang]

there is another choice now: http://www.php.net/manual/en/intro.opcache.php
For using very large shared memory, you need to write to the developer of each opcode cache, they can give you accurate answers.