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 Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
33 - 5 = ?
Subscribe to this entry?

 
 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 13:01:29 2024 UTC