php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #57591 High memory consumption with APC and Aapache 1.3.37
Submitted: 2007-03-26 07:48 UTC Modified: 2007-03-29 10:48 UTC
From: pbugs at ausschlafen dot com Assigned:
Status: Closed Package: APC (PECL)
PHP Version: Irrelevant OS: 2.4.16-64GB-SMP
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: pbugs at ausschlafen dot com
New email:
PHP Version: OS:

 

 [2007-03-26 07:48 UTC] pbugs at ausschlafen dot com 
Description:
------------
Hi,

after enabling APC on a heavily loaded production server,
the server almost died due to memory shortage ...

I took a look at the memory consumption; this is what
happens:

without APC, I have maximum sizes of about 15 MB per
apache process, with an average of about 10 MB. So
I can afford to start 300 Apache childs on this
4 GB RAM server.

With APC enabled, the memory usage per child doubled. I had
peak sizes of 30 MB and more regularly and an average
size of 20+ MB. So having 300 childs and only 4 GB RAM
you can imagine what happens ... 

Is this a bug or just expected behaviour - i.e. is this
the price for using APC? Since I did not find any 
hint/warning in the docs, I am going to submit it as a bug.

These are the old APC settings I had in php.ini

#extension="apc.so"
#apc.enabled=1
#apc.shm_segments=1
#apc.optimization=0
#apc.shm_size=64
#apc.ttl=3600
#apc.user_ttl=3600
#apc.gc_ttl=3600
#apc.num_files_hint=0
#apc.user_entries_hint=0
#apc.mmap_file_mask=/tmp/apc_k.XXXXXX
#apc.enable_cli=0
#apc.cache_by_default=On
#apc.filters="-/suche/"
#apc.slam_defense=20
#apc.file_update_protection=5
#apc.max_file_size=1M
#apc.stat=1

APC compiled with
./configure --enable-apc --enable-apc-mmap --with-apxs=/usr/local/apache-1337-php446/bin/apxs --with-php-config=/usr/local/php446/bin/php-config

PHP compiled with:
./configure  --prefix=/usr/local/php446 --with-apxs=/usr/local/apache-1337-php446/bin/apxs --with-mysql=/usr/local/mysql --with-zlib-dir=/usr --with-zlib --with-config-file-path=/usr/local/php446 --with-pcre-regex=/opt/pcre/ --enable-versioning


Best Regards,
Ulrich

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-26 14:07 UTC] gopalv82 at yahoo dot com 
Please change line 

http://cvs.php.net/viewvc.cgi/pecl/apc/apc_compile.c?view=annotate#l2005

to needcopy = 0; and do a retest ? Because that seems a 
likely suspect, except I don't have enough code around to max 
out my memory this way.
 [2007-03-28 02:45 UTC] gopalv82 at yahoo dot com 
Cut down on the redundant memory copy in code 

http://news.php.net/php.pecl.cvs/7586

Please update bug if not fixed.
 [2007-03-28 05:35 UTC] pbugs at ausschlafen dot com 
Hi, 

I have this version of apc_compile.c:
(from the latest .13 package):

apc_compile.c,v 3.75 2007/02/06 22:05:15 gopalv Exp

patched with the patches recommended in
http://pecl.php.net/bugs/bug.php?id=10419

Now the code around the "needcopy" looks completely different:


   1938     int i=src->last;
   1939     zend_op *zo;
   1940     zend_op *dzo;
   1941 #ifdef ZEND_ENGINE_2
   1942     apc_opflags_t * flags = APCG(reserved_offset) != -1 ?
   1943                                 (apc_opflags_t*) & (src->reserved[APCG(r
        eserved_offset)]) : NULL;
   1944     int needcopy = flags ? flags->deep_copy : 1;
   1945     /* auto_globals_jit was not in php4 */
   1946     int do_prepare_fetch_global = PG(auto_globals_jit) && (flags == NULL
         || flags->use_globals);
   1947 #else
   1948     int needcopy = 1;
   1949     int do_prepare_fetch_global = 0;
   1950 #endif
   1951
   1952     if(needcopy) {
   1953
   1954         dst->opcodes = (zend_op*) apc_xmemcpy(src->opcodes,
   1955                                     sizeof(zend_op) * src->last,
   1956                                     apc_php_malloc);
   1957         zo = src->opcodes;


Should I change line 1948 to needcopy=0 
or better get a new Checkout of the whole package? Since I 
would like to go in production with APC I would prefer going the "safer" way.

Best Regards,
Ulrich
 [2007-03-29 00:00 UTC] gopalv82 at yahoo dot com 
The "change needcopy = 0" was an intermediate test to know if that was indeed the problem.

What is in CVS is a clean & proper fix to detect needcopy for php4 [which mysteriously (*heh*) dissappeared during the last cycle of optimisations]. So pull CVS and try it out or wait a few more days for 3.0.14 to be release ready.

Anyway, your current setup looks like it can't handle the load it is put on. Because while a file is being compiled in apc (i.e cache WRLOCKed), the default compile is likely to hit memory boundaries and got into a swap thrash.
 [2007-03-29 10:48 UTC] pbugs at ausschlafen dot com 
Well, you're telling me ...
I know that this server is closer to death than to life,
and thats why I thought APC could maybe help a little
bit.

I better wait until *.14 and try again when it is released.

Just for the records, I recompiled with needcopy=0 in 
that specific line (1948 in the version 3.75 of compile.c)
and tried it in an offpeak hour. Nevertheless, RAM size
per child still exceeded the usual size significantly.
I didn't wait how far it would go up, but probably it would
have been doubled again.

I am closing this bug report for now, let's see how it
works with .14

Thanks and best regards,
Ulrich
Ulrich
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Jul 04 20:01:35 2025 UTC