emalloc / erealloc again with APC

#1
Hi,

I'm getting emalloc / erealloc errors in stderr.log which cause one of my vhosts not to work (I always get a 503 error). The single vhost which isn't working is serving a MediaWiki installation. The other (working) vhosts serve simple php-sites.

1) Ubuntu Dapper 6.06.1 64bit,
Linux peach 2.6.17.8 #4 Fri Aug 11 21:13:01 CEST 2006 x86_64 GNU/Linux

2) LiteSpeed 2.1.19 Standard

3) PHP 5.1.4 with LSAPI and APC 3.0.10

4) The wiki worked after I installed the LiteSpeed server (it's maybe 8 hours ago) and when I just looked, I got the 503 error. The only error-message I get is in stderr.log and says:

FATAL: erealloc(): Unable to allocate 30720 bytes
FATAL: erealloc(): Unable to allocate 30720 bytes
FATAL: emalloc(): Unable to allocate 7680 bytes
FATAL: emalloc(): Unable to allocate 7680 bytes
[...][Wed Aug 16 17:20:51 2006] [apc-error] apc_mmap: mmap failed: Cannot allocate memory
[Wed Aug 16 17:20:51 2006] [apc-error] apc_mmap: mmap failed: Cannot allocate memory
[Wed Aug 16 17:20:52 2006] [apc-error] apc_mmap: mmap failed: Cannot allocate memory
[...]
FATAL: emalloc(): Unable to allocate 7680 bytes
FATAL: emalloc(): Unable to allocate 7680 bytes
FATAL: erealloc(): Unable to allocate 30720 bytes
FATAL: erealloc(): Unable to allocate 30720 bytes

My setup is:
Server->Tuning:
Max Cached Small File Size (bytes) 4096
Total Small File Cache Size (bytes) 20M
Max MMAP File Size (bytes) 1M
Total MMAP Cache Size (bytes) 128M

Max Request Header Size (bytes) 8192
Max Request Body Size (bytes) 1G
Max Dynamic Response Header Size (bytes) 8K
Max Dynamic Response Body Size (bytes) 1G

VHost Template -> External App Definition (excerpt):
Name: $VH_NAME-php
Address: uds://tmp/lshttpd/$VH_NAME-php.sock
Max Connections: 20
Environment: PHP_LSAPI_MAX_REQUESTS=500
Instances: 20
Memory Soft Limit (bytes) 0
Memory Hard Limit (bytes) 0
Process Soft Limit 0
Process Hard Limit 0

I tried setting these limits to a very high number (memory about 160MB) instead of 0, but this didn't change anything. I restarted the server several times. If you need any more information, just tell me. :)

Regards,
Philipp
 

xing

LiteSpeed Staff
#2
Philipp,

Please try with "Server > Security > CGi Resources" memory soft/hard settings set also to "0" and/or a very high value.

Should not make a difference we want to test all scenarios to see if this is an internal config problem or an external problem.

Also make sure in php.ini that you have disabled max-memory limit option if that feature is compiled in.
 
Last edited:
#3
Setting both memory limits to 0 or alternatively to soft: 200M, hard: 240M "fixes" the error, setting it to a low value like 20M brings a 503 error again! :) Now, is this the real solution to disable memory limits or is it still a bug but disabling the limit just hides it?

Edit: I encountered the error again during a Wordpress installation with memory limits soft: 200M, hard: 240M.
Edit 2: Sorry, this may have happened because of other memory limits set in this special VHost template.. (Edit 3, yes, it was because of these limits. Removed all memory limits but soft: 200M, hard: 240M in Server -> Security -> CGI Resources -> Memory soft/hard settings and it's still running fine)
 
Last edited:

gboudreau

Well-Known Member
#5
Using LiteSpeed 2.2.2 standard, APC 3.0.12p2 and PHP 5.1.6 LSAPI.

I am also getting
Code:
FATAL: emalloc(): Unable to allocate x bytes
in my stderr.log when I have APC enabled.
This happens when I use a self-created PHP script which loads a 8MB serialized (on disk) object and plays with it. Didn't try to see what exactly in my script made it spit this error; I would guess it errors out when loading the object.
The only way I found to make it work is to disable apc in php.ini

I tried using either 0 or high values (300M/450M) as memory soft/hard limits in both Server > Security > CGI Resource and VHost > External Apps > LSAPI App, but it didn't help al all.

Thanks for any pointer on how to resolve / debug.
 

gboudreau

Well-Known Member
#7
php.ini: memory_limit = 600M
Server > Security > CGI Resource: memory limits = 600M / 700M
VHost > External Apps > LSAPI App: memory limits = 600M / 700M

Restarted lsws to make sure the new limits were used.

Also tried 0 / 0 as memory limits.

All with same result:
FATAL: emalloc(): Unable to allocate 16 bytes
FATAL: emalloc(): Unable to allocate 16 bytes
 
Last edited:

mistwang

LiteSpeed Staff
#8
Please check your default memory limit with "ulimit -a" from command line. LSWS may not able to raise above that limit when PHP is not started in setUIDMode.
 

gboudreau

Well-Known Member
#9
I'm using the PHP_SuEXEC template that came with 2.2.2 for this virtual host.

Code:
[root@megaone ~]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8063
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
max rt priority                 (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 8063
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
file locks                      (-x) unlimited
 

gboudreau

Well-Known Member
#11
It works from the command line with APC enabled:

Code:
[root@megaone fcgi-bin]# ./lsphp5 -i | grep apc
apc
apc.cache_by_default => On => On
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.optimization => Off => Off
apc.report_autofilter => Off => Off
apc.shm_segments => 1 => 1
apc.shm_size => 30 => 30
apc.slam_defense => 0 => 0
apc.stat => On => On
apc.ttl => 0 => 0
apc.user_entries_hint => 100 => 100
apc.user_ttl => 0 => 0
apc.write_lock => On => On
[root@megaone fcgi-bin]# ./lsphp5 ../www-html/data.titantv.com/dataservice.asmx/RequestLineupData
<?xml version="1.0" encoding="utf-8"?>
[...]
But not using LiteSpeed:
Code:
[root@megaone fcgi-bin]# curl -i http://data.titantv.com/dataservice.asmx/RequestLineupData
HTTP/1.1 503 Service Unavailable
Server: LiteSpeed
Date: Mon, 02 Oct 2006 17:29:53 GMT
Connection: close
Cache-Control: private, no-cache, max-age=0
Pragma: no-cache
Content-Type: text/html
Content-Length: 401

<html>
<head><title> 503 Service Unavailable
</title></head>
<body><h1> 503 Service Unavailable
</h1>
The server is temporarily busy, try again later!<hr />
Powered By <a href='http://www.litespeedtech.com'>LiteSpeed Web Server</a><br />
<font face="Verdana, Arial, Helvetica" size=-1>Lite Speed Technologies is not responsible for administration and contents of this web site!</font></body></html>
If you would like access to the machine to speed things up, it can be arranged. Just PM me your IM contacts.

Thanks again.
 

xing

LiteSpeed Staff
#13
Guillaume/Bambito,

You can contact me via AIM at handle: "litespeedtech". Please note I am on the US West Coast PST time. I will be willing to talk to you and access your machines to find out exactly what os/app parameter is causing this.

Xing
 

xing

LiteSpeed Staff
#14
We have found that the use of APC can artificiallly accelerate PHP's memory usage/requirement for certian scripts/operations, i.e. deserialize() large serialized packets. Most likely a problem within APC.

We recommend that users of APC/PHP that encounter the emalloc() errors to increase memory ceiling for external processes via LiteSpeed admin:

Either server wide:
Server > Security > CGI Resource: memory limits (soft/hard) = 200M / 200M

Or on per extapp basis:
VHost > External Apps > LSAPI App: memory limits (soft/hard) = 200M / 200M


Tweak, increase or decrese the values to fit your enviornment to remove emalloc() errros.
 
Top