[Resolved] XCache: PHP Out of memory if cache size > 64M

G

gmichels

Member
#1
#1
Hi all,

I have an IPB3 forum running on the following hardware:

- 8 core Intel i7 2.67 GHz
- 12 GB RAM
- 2x SATA HDDs

And software:

- LiteSpeed 4.0.16 (4-cpu license)
- PHP 5.3.3

The forum online user count usually ranges from 500-1200.

I tried to use eAccelerator first, but it had some big issues (100% cpu usage sometimes, never seen the load avg so high) and had to drop it. Now I'm trying XCache and I must say I already like it MUCH better than eAccelerator.

I'm using these settings:

Code: 
xcache.size="64M"
xcache.count="8"
xcache.ttl="300"
xcache.var_size="8M"
xcache.var_count="8"
xcache.var_ttl="300"
xcache.stat="Off"
The problem is the cache gets filled after a few minutes and I get a lot of OOMs on the admin page. So I should increase the cache size, however I get loads of PHP out of memory errors if I set it to anything over 64M:

Code: 
[STDERR] PHP Fatal error:  Out of memory (allocated 14417920) (tried to allocate 32 bytes)
[STDERR] PHP Fatal error:  Out of memory (allocated 13631488) (tried to allocate 83 bytes)
[STDERR] PHP Fatal error:  Out of memory (allocated 13631488) (tried to allocate 3 bytes)
Here are my sysctl values:

Code: 
# sysctl -a |grep shm
kernel.shmmax = 1073741824
kernel.shmall = 262144
kernel.shmmni = 4096
vm.hugetlb_shm_group = 0
Adding xcache.gc_interval="120" does help as seldomly accessed scripts are removed from the cache and memory is freed, however I still would like to increase my cache size.

Any clues?

Thanks
 
Last edited by a moderator:
N

NiteWave

Administrator
#2
#2
assume php in non-suExec mode? php in suExec mode not utilize opcode cache efficiently.

what's the memory limit setting for a php process? it can set in php.ini like normal php, also there are "Memory Soft/Hard Limit" setting for lsphp.

How about try APC? performance-wise, APC should not be worse than XCache or even better. If APC can set shared memory > 64M or 128M without any problem, you can get quick answer to your question.
 
Last edited:
G

gmichels

Member
#3
#3
NiteWave said:
assume php in non-suExec mode? php in suExec mode not utilize opcode cache efficiently.
Click to expand...
No, php is not running in suExec mode.

NiteWave said:
what's the memory limit setting for a php process? it can set in php.ini like normal php, also there are "Memory Soft/Hard Limit" setting for lsphp.
Click to expand...
You mean memory_limit in php.ini? It's set to 128M. Should this setting be raised to include the cache memory size?

Settings for lsphp are 250M soft and 300M hard.

NiteWave said:
How about try APC? performance-wise, APC should not be worse than XCache or even better. If APC can set shared memory > 64M or 128M without any problem, you can get quick answer to your question.
Click to expand...
I just installed APC and I get the same thing, cache size up to 64M is ok, more than that PHP Out of Memory errors all over the log.

Thanks for your time!
 
G

gmichels

Member
#5
#5
mistwang said:
Yes, that's correct.
Click to expand...
Increased memory_limit to 256M and cache size to 128M, still got out of memory errors. However I tried the cache size at 96M and it is working now, so indeed increasing the limit seems to be the solution.

Should I still increase the memory_limit and cache size until I don't get 100% cache usage? Is there any danger in doing so? I do use TTLs for deleting unused scripts.

Thanks
 
M

mistwang

LiteSpeed Staff
#6
#6
For running PHP without suEXEC, you can set cache memory size high as one group PHP processes only use one copy of cache. It is up to you and the available memory of your server.
 
G

gmichels

Member
#7
#7
I increased memory_limit to 512M but I still can't go over 96M for cache size. I have also posted [1] this same problem on xcache's forum and one user there had xcache working with cache size 256M and php memory_limit 128M, so it seems increasing memory_limit is not the solution.

Unfortunately I don't know what else to do :(

[1] I can't post links as I don't have enough posts to do so
 
You must log in or register to reply here.
Top