PHP Garbage Collector statistics - php

I'm doing some PHP memory benchmarks and i would like to obtain the garbage collector statics.
I've followed this tutorial in the official doc: http://www.php.net/manual/en/features.gc.performance-considerations.php
I've reproduced the exact procedure wich is described, by recompiling PHP with this CFLAGS environment variable :
export CFLAGS=-DGC_BENCH=1
./config.nice
make clean
make
make install
I've done that with PHP 5.3.9 : http://fr.php.net/get/php-5.3.9.tar.bz2/from/a/mirror on a Debian Squeeze 6.0.4 64bits.
Then i tried to execute in command line the example script they provide php gc.php :
<?php
class Foo
{
public $var = '3.1415962654';
}
for ( $i = 0; $i <= 1000000; $i++ )
{
$a = new Foo;
$a->self = $a;
}
echo memory_get_peak_usage(), "\n";
?>
As they said, this should display at the end of the script, additional gc stats, for exemple :
GC Statistics
-------------
Runs: 110
Collected: 2072204
Root buffer length: 0
Root buffer peak: 10000
Possible Remove from Marked
Root Buffered buffer grey
-------- -------- ----------- ------
ZVAL 7175487 1491291 1241690 3611871
ZOBJ 28506264 1527980 677581 1025731
The fact is, this gc statistics aren't displayed.
It looks like that compiling PHP with this CFLAGS didn't made anything.
Did i missed something ?

I'm going on a hunch here as I've not confirmed this but, from reading the text on the GC link you provided, I don't get the impression that memory_get_peak_usage() should return additional information based on compiling PHP with the DGC_BENCH flag. The manual says it returns an int, so I suspect it always returns an int.
What it does say however is:
When you run the above example code again with the newly built PHP
binary, you will see the following being shown after PHP has finished
execution:
That isn't very clear, but I'm under the impression that the additional GC details will be printed to stdout or stderr rather than returned to memory_get_peak_usage() or being printed as additional output to your PHP script.
Try calling the newly built PHP executable from the command line and see if the GC information is printed to the console when the script finishes.
You can try calling it like: /path/to/custom/php testfile.php
I'm not sure it makes sense to output this information if you were running PHP as an Apache module or FastCGI handler so I suspect you may only be able to see it by calling your script from the console, but I could be totally wrong there.
UPDATE:
I've checked to make sure that the GC_BENCH compile flag is still active, and it is.
Zend/zend.c
905 #if GC_BENCH
906 fprintf(stderr, "GC Statistics\n");
907 fprintf(stderr, "-------------\n");
908 fprintf(stderr, "Runs: %d\n", GC_G(gc_runs));
909 fprintf(stderr, "Collected: %d\n", GC_G(collected));
910 fprintf(stderr, "Root buffer length: %d\n", GC_G(root_buf_length));
911 fprintf(stderr, "Root buffer peak: %d\n\n", GC_G(root_buf_peak));
912 fprintf(stderr, " Possible Remove from Marked\n");
913 fprintf(stderr, " Root Buffered buffer grey\n");
914 fprintf(stderr, " -------- -------- ----------- ------\n");
915 fprintf(stderr, "ZVAL %8d %8d %9d %8d\n", GC_G(zval_possible_root), GC_G(zval_buffered), GC_G(zval_remove_from_buffer), GC_G(zval_marked_grey));
916 fprintf(stderr, "ZOBJ %8d %8d %9d %8d\n", GC_G(zobj_possible_root), GC_G(zobj_buffered), GC_G(zobj_remove_from_buffer), GC_G(zobj_marked_grey));
917 #endif
Next, I compiled PHP 5.3.9 for Apache2 and CLI. Before deciding to install the test version, I ran the new PHP CLI app from the console:
./sapi/cli/php -v
PHP 5.3.9 (cli) (built: Feb 22 2012 19:03:02)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
GC Statistics
-------------
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 7
Possible Remove from Marked
Root Buffered buffer grey
-------- -------- ----------- ------
ZVAL 15 7 7 0
ZOBJ 0 0 0 0
It has the GC output even though I didn't invoke PHP. Next I grep'd libphp5.so and saw that it DOES have the GC Statistics bit compiled into it so I decided to install it live and make a call from Apache. No GC output in the browser, error_log, access_log, or any other log files.
Now the interesting part, I created a test.php file which outputs a string and creates a frees a few variables...
root#vm:/php539# php test.php
This is a test
root#vm:/php539# php < test.php
This is a test
GC Statistics
-------------
Runs: 0
Collected: 0
Root buffer length: 0
Root buffer peak: 7
Possible Remove from Marked
Root Buffered buffer grey
-------- -------- ----------- ------
ZVAL 16 7 7 0
ZOBJ 0 0 0 0
root#vm:php539#
Conclusion:
When PHP is compiled with with GC_BENCH option, you will not have access to benchmark information when called from the browser, or when parsing PHP files by using the -f option or passing the name of the file to parse. You DO get benchmark information if you call php in interactive mode, or execute the script through PHP by reading it from stdin.

Related

PostgreSQL server doesn't release memory until connection from PHP/Laravel client is closed

I have a daemon written in PHP/Laravel that connects to a PostgreSQL database using PDO and executes jobs from a queue. A job typically takes 30 minutes to run. It consists of several PostgreSQL queries with PostGIS.
With every SQL query server memory usage increases. The memory is freed only when the connection is closed. So if I run several jobs consecutively the server eventually runs out of memory.
I have been able to temporarily solve the problem by having my daemon periodically reconnect to the database. However, why does the memory not get released unless I disconnect from the server?
Some details about the environment:
In queries I use PostGIS functions ST_Contains(), ST_GeomFromText(), ST_Area() for SELECTs and other simple plain SQL SELECTs with similar UPDATE.
Example of query:
select id
from gtn
where ST_Contains(geo_polygon::geometry, ST_GeomFromText('POINT(0.000000 0.000000)', 4326))
order by ST_Area(geo_polygon::geometry) asc;
All PostgreSQL settings are default, except one:
effective_cache_size = 1GB
Tuning the settings using this tool did not help:
# DB Version: 12
# OS Type: linux
# DB Type: web
# Total Memory (RAM): 4 GB
# CPUs num: 2
# Data Storage: ssd
max_connections = 200
shared_buffers = 1GB
effective_cache_size = 3GB
maintenance_work_mem = 256MB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 2621kB
min_wal_size = 1GB
max_wal_size = 4GB
Connection to PostgreSQL using PHP PDO;
Laravel: v5.7.29;
PHP:
PHP 7.4.33 (cli) (built: Nov 15 2022 06:05:55) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies
with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans
Docker image: postgres:12;
PostgreSQL:
# psql --version
psql (PostgreSQL) 12.13 (Debian 12.13-1.pgdg100+1)
PostGIS:
# psql -U postgres -c 'SELECT PostGIS_Full_Version();'
postgis_full_version
------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------
POSTGIS="3.3.2 4975da8" [EXTENSION] PGSQL="120" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 5.2.0, September 15th, 201
8" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.3.1" WAGYU="0.5.0 (Internal)"
(1 row)
Also, I found this, but there has not any solution.
UPD: 2023-02-18
As said jjanes, I've executed the follow query 100 times using PHP PDO (without Laravel at all) and psql CLI:
select id
from gtn
where "view" is not null
and geo_polygon is not null
and ST_Contains(geo_polygon::geometry, ST_GeomFromText('POINT(0.000000 0.000000)', 4326))
order by ST_Area(geo_polygon::geometry) asc
limit 2;
After this, memory of postgres process was increased by 50 Mb, both PHP PDO and psql CLI. Only after disconnect from the DB the memory got released.
Then I've run the simple query 100 times:
select id from gtn limit 100;
when my memory has been increased only by 1 Mb and didn't increase during execution anymore. The memory got released only after disconnect too.
Using PHP PDO I tried to run gdb. I added to dockere-compose.yml service of postgres the following config:
cap_add:
- SYS_PTRACE
security_opt:
- seccomp:unconfined
and installed postgresql-12-dbgsym postgresql-12-postgis-3-dbgsym gcc gdb libc6-dbg libffi6-dbg libgcc1-dbg libkrb5-dbg libstdc++6-8-dbg libxml2-dbg zlib1g-dbg libkrb5-dbg packages.
I run my query again using PHP PDO and after executed query 100 times, gdb showed me next:
$ gdb -p 70
...
(No debugging symbols found in /usr/lib/x86_64-linux-gnu/libmd.so.0)
Cannot access memory at address 0x7f5264494088
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Failed to read a valid object file image from memory.
Unable to read JIT descriptor from remote memory
0x00007f526367ad16 in epoll_wait (epfd=3, events=0x55f87ab9cfb8, maxevents=1, timeout=-1)
at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30 ../sysdeps/unix/sysv/linux/epoll_wait.c: No such file or directory.
I could not even execute p MemoryContextStats(TopMemoryContext) for gdb, because I get a Couldn't get extended state status: No such process. error.

qcachegrind error: Unknown file format. File generated from php xdebug

I am attempting to use xdebug to profile an application written in php7.
I've written a script that sets the follow ini settings:
ini_set('xdebug.trace_format',1); // Note: I tried 0 and 2 here as well
ini_set('xdebug.profiler_enable',1);
xdebug_start_trace('/tmp/cachegrind.out');
// RUN CODE HERE
xdebug_stop_trace();
Running the script created the cachegrind files as I would expect:
root#host:/# ls /tmp | grep cachegrind
cachegrind.out.0028fd.xt
cachegrind.out.0072ab.xt
cachegrind.out.009b09.xt
cachegrind.out.025ac3.xt
Here is the first few lines of a cachegrind file so that the format is visible:
Version: 2.4.1
File format: 4
TRACE START [2016-10-28 05:26:57]
2 3784 1 0.242945 2692856
2 3785 0 0.242955 2692800 DI\Container->set 1 /path/public/api/index.php 100
2 3785 1 0.242966 2692800
2 3786 0 0.242973 2692800 spl_autoload_call 0 /path/public/api/index.php 103
3 3787 0 0.242982 2692896 Fuel\Core\Autoloader::load 1 /path/public/api/index.php 103
4 3788 0 0.242990 2692896 strpos 0 /path/fuel/core/classes/autoloader.php 219
However, when I try to open this file in qcachegrind, it fails to open:
The error message reads: "Error loading /path/to/cachegrind/file: Unknown file format
Anyone know what's going on here? I'd like to be able to use a tool like this to profile my application.
I also shelled out $30 to try opening the file in MCG but that app crashes immediately upon opening any of these files.
As a side note, the file is fairly large, but not so large that I'd expect apps to be freaking out:
❯ ls -al /Users/johnpc/repos/cachegrind.out.094ffa.xt
-rw-r--r-- 1 johnpc staff 62744095 Oct 28 02:13 /Users/johnpc/repos/cachegrind.out.094ffa.xt
that file is a trace file not a callgrind file.
i seems you set trace_output_name and profiler_output_name in the ini to the same string or trying to open the wrong file. you need to set the profiling_* variables in the ini.
see: "Profiling PHP Scripts" in the xdebug docs
a sample profiling output looks like this:
version: 1
creator: xdebug 2.1.1rc1
cmd: /Users/foo/bar/test1.php
part: 1
positions: line
events: Time
fl=php:internal
fn=php::microtime
when you get problems because of the file size, you could also try the app from profilingviewer.com

I am facing more memory consumption in Php 7 compare to PHP 5.6

When I was doing a benchmark, I found that PHP 7 was using more memory than PHP 5.6.
So, I did a test. I ran a script containing only:
$a=10;
and below are the results for the memory used when I used PHP CLI without any modules (php -n)
php 5.6 = 222600 Bytes
php 7.0 = 350448 Bytes
* PHP 5.6.23 (cli) (built: Jun 22 2016 12:13:15)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
* PHP 7.0.9 (cli) (built: Jul 20 2016 10:47:41) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
Environment is
OS: window 10
Server : IIS (although I used the CLI, not the server), with fast cgi
machine : 64 bit
php-5.6.23-nts-Win32-VC11-x64
php-7.0.9-nts-Win32-VC14-x64
Can anyone explain why I got this result?
Additional Tests
Using this code, as suggested by #gordon,
$i=0;
while ($i++ < 100000) ;
php 5.6: 227408 bytes
php 7.0: 386640 bytes
I determined memory usage with this code:
echo PHP_EOL;
echo "Memory Usage :".memory_get_usage();
echo PHP_EOL;
echo "Real Memory Usage :".memory_get_usage(true);
echo PHP_EOL;
echo "Real Peak Memory Usage :".memory_get_peak_usage(true);
echo PHP_EOL;
echo "Peak Memory Usage :".memory_get_peak_usage();
To understand the answer to your question - you need understand how PHP5 and PHP7 allocs memory.
PHP5 allocating memory "By Request" assuming by it's Zend Engine structure.
In PHP7 it's some optimizations made at this side, so on memory allocating "by the chunks"
On start it allocates large chunk of memory
On in-app allocation it allocates small chunk to avoid fragmentation
This differences makes very good increasing of performance (because of engine don't need allocate memory on runtime every time you need it and save some time on fragmentation), but it increases memory consumption for "very small" programs, which size is below than "chunk size".
And yes, PHP7 saves memory very much on large programs.
You may view all this differences in pictures below:
Graphics builded with benchmark:
1.php
<?php
ini_set('memory_limit', '5G');
$a=range(1,$argv[1]);
echo PHP_EOL;
echo "Memory Usage :".memory_get_usage();
echo PHP_EOL;
echo "Real Memory Usage :".memory_get_usage(true);
echo PHP_EOL;
echo "Real Peak Memory Usage :".memory_get_peak_usage(true);
echo PHP_EOL;
echo "Peak Memory Usage :".memory_get_peak_usage();
echo PHP_EOL;
bench.sh
// Small programs
(for i in $(seq 0 5 5000);do php5 dev/Tools/mem/1.php $i|cut -f 2 -d:|sed -r 's/^$/;/g'|sed -r 's/([0-9]+)$/\1,/g'|tr -d '\n'; echo $i; done)|tr -d '\n'|sed -r 's/$/]/g'|sed -r 's/^;/[/g'>php5.m
(for i in $(seq 0 5 5000);do php dev/Tools/mem/1.php $i|cut -f 2 -d:|sed -r 's/^$/;/g'|sed -r 's/([0-9]+)$/\1,/g'|tr -d '\n'; echo $i; done)|tr -d '\n'|sed -r 's/$/]/g'|sed -r 's/^;/[/g'>php7.m
//Large Programs
(for i in $(seq 0 50 100000);do php5 dev/Tools/mem/1.php $i|cut -f 2 -d:|sed -r 's/^$/;/g'|sed -r 's/([0-9]+)$/\1,/g'|tr -d '\n'; echo $i; done)|tr -d '\n'|sed -r 's/$/]/g'|sed -r 's/^;/[/g'>php5.m
(for i in $(seq 0 50 100000);do php dev/Tools/mem/1.php $i|cut -f 2 -d:|sed -r 's/^$/;/g'|sed -r 's/([0-9]+)$/\1,/g'|tr -d '\n'; echo $i; done)|tr -d '\n'|sed -r 's/$/]/g'|sed -r 's/^;/[/g'>php7.m
octave drawer
php7;php7=ans;
php5;php5=ans;
plot(php5(:,5)',[php5(:,1:4)';php7(:,1:4)']');
legend("PHP5 mgu", "PHP5 rmu", "PHP5 rpmu", "PHP5 pmu","PHP7 mgu", "PHP7 rmu", "PHP7 rpmu", "PHP7 pmu");
Read more
Official PHP7/PHP-NG presentation:
https://drive.google.com/file/d/0B3UKOMH_4lgBUTdjUGxIZ3l1Ukk/view
Official PHP7/PHP-NG internal changes description:
https://wiki.php.net/phpng-int
Official extension migration guide:
https://wiki.php.net/phpng-upgrading
Good articles from #NikiC:
http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html
and
http://nikic.github.io/2015/06/19/Internal-value-representation-in-PHP-7-part-2
PHP5 internal details: http://www.phpinternalsbook.com/
Badoo PHP5->PHP7 success story with details: https://techblog.badoo.com/blog/2016/03/14/how-badoo-saved-one-million-dollars-switching-to-php7/
Your tests show more memory usage in PHP 7.0 because the testing code is very simple.
PHP 7.0 is known to use less memory (and be faster) that PHP 5.6 due to a radical rewrite of the internal ZEND Engine (the interpreter core)
As Gordon commented most likely the new features and improvements in PHP 7.0 require a "bootstrap" that result in negative results when tested on small pieces of code.
Let's try it with something more complex: build an array of 10.000 integers then sort it using Quicksort algorythm.
Here is the result I get:
PHP 7.0
Memory Usage: 1432752
Real Memory Usage: 4194304
Real Peak Memory Usage: 4194304
Peak Memory Usage: 3152360
PHP 5.6
Memory Usage: 2756744
Real Memory Usage: 4980736
Real Peak Memory Usage: 6029312
Peak Memory Usage: 5710464
And still a simple 20 lines quicksort is way far from real world applications with thousands of lines of codes, many classes declarations, many instances...
I have run the test on http://phptester.net
Below is the code
<?php
function quick_sort($array)
{
$length = count($array);
$pivot = $array[0];
$left = $right = array();
for($i = 1; $i < count($array); $i++)
{
if($array[$i] < $pivot)
{
$left[] = $array[$i];
}
else
{
$right[] = $array[$i];
}
}
return array_merge(quick_sort($left), array($pivot), quick_sort($right));
}
$unsorted = array();
for($i=0;$i<10000;$i++)
{
$unsorted[] = rand(1,1000000);
}
$sorted = quick_sort($unsorted);
$lf = "<br/>";
echo $lf;
echo "Memory Usage: ".memory_get_usage();
echo $lf;
echo "Real Memory Usage: ".memory_get_usage(true);
echo $lf;
echo "Real Peak Memory Usage: ".memory_get_peak_usage(true);
echo $lf;
echo "Peak Memory Usage: ".memory_get_peak_usage();
echo $lf;
Credit for the quicksort algorythm in PHP: http://andrewbaxter.net/quicksort.php
Upfront I want to say that if you see higher reported memory usage in PHP 7 on real code, the most likely cause is that PHP 7 will report memory usage of mysqlnd buffered queries as part of the memory usage. In PHP 5 this memory usage was not reported (but of course the memory was still used). For large queries this can make a very substantial difference.
Now to your actual case, which is basically the memory usage of PHP immediately after request startup. The answer by MobDev already explains why there is a discrepancy in "real" memory usage, which is the memory usage metric which reports how much memory PHP's allocator has requested from the system allocator of kernel. As MobDev points out PHP 7 will allocate memory in much larger chunks (2MB) and is also more aggressive about caching allocated chunks.
However this does not explain the discrepancy in "non-real" memory usage, which does not take these allocator details into account. It is easy to check whether exactly the memory goes by using a memory profiler, e.g. by running PHP through USE_ZEND_ALLOC=0 valgrind --tool=massif. The USE_ZEND_ALLOC=0 part instructs PHP to not use its own allocator.
First of all this will show you that the actual memory usage and the memory usage reported by PHP differ quite significantly. Massif will show 3.2MB usage for PHP 5.6 and 2.3MB for PHP 7. The reason is that PHP only reports memory that goes through it's own allocator (ZMM), while many structures that survive across multiple request are not allocated using it.
The largest allocations going through the system allocator (thus not reported in the memory usage) are:
| PHP 5.6 | PHP 7
interned string buffer | 1 MB | 150 KB + strings
GC buffer | 320 KB | 320 KB
internal classes/funcs | >1.3 MB | >0.5 MB
The "internal classes/funcs" number is a crude lower bound, because there are many small allocations involved here which are hard to count. One main difference is visible, which is that PHP 7 does not use a fixed interned string buffer (the listed size is the for the hashtable buffer I'm seeing, which does not include the size of the strings themselves).
However, this still doesn't answer the question of the actually reported memory usage. In this case the largest allocations are:
| PHP 5.6 | PHP 7
VM stack | 130 KB | 256 KB
Object store | 64 KB | (8 KB)
CG arena | --- | 64 KB
There are a couple of differences here. The main one is that PHP 7 uses a larger VM page size (about twice as large). Additionally PHP 7 uses an arena to store certain structures (like user functions), which starts off with a default size of 64KB. On the other hand the size of the object store buffer is significantly smaller in PHP 7.
So essentially the TL;DR answer is that PHP 7 uses a larger VM stack page size.
Php 5.6 requires less bytes as compared to Php 7.0.

memory_get_usage seems inaccurate, how can I further diagnose a memory leak in PHP?

I'm seeing my long running php processes utilize significant amounts of memory, and it grows very quickly. After about a day, I saw the following:
# pmap <pid>
000000000091c000 588K rw--- /usr/bin/php
00000000009af000 108K rw--- [ anon ]
00000000013ab000 256948K rw--- [ anon ]
00007f9ed0000000 132K rw--- [ anon ]
...
00007f9edcaa6000 8K rw--- /usr/lib64/php/modules/curl.so
00007f9edcaa8000 103580K r---- /usr/lib/locale/locale-archive
...
total 629312K
# cat /proc/<pid>/status
Name: php
State: S (sleeping)
...
VmHWM: 268920 kB
VmRSS: 268920 kB
VmData: 334368 kB
VmStk: 136 kB
VmExe: 3188 kB
VmLib: 22752 kB
VmPTE: 912 kB
VmSwap: 0 kB
Threads: 1
...
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 11902137
ps aux
0.5 4.3 694124 333864 ? S Jan21 8:11 php
top
PR NI VIRT RES SHR S %CPU %MEM TIME+ CODE DATA COMMAND
20 0 677m 326m 9100 S 0.0 4.4 8:11.56 3188 390m php
but, memory_get_usage(true) consistently returns:
1835008
There seems to be a memory leak, but how can I diagnose the cause, and reduce it? I've tried to utilize tools such as this, but similar to memory_get_usage, it doesn't notice any additional memory usage
I've also tried:
# strace -p -e trace=memory
but all I see are brk() calls, like so:
brk(0) = 0x14f6f000
brk(0x14f90000) = 0x14f90000
I'm on version 5.4.27:
# php --version
PHP 5.4.27 (cli) (built: Apr 23 2014 23:34:13)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
You can compile PHP on your own using the --enable-debug configure option. If you execute a php cli script compiled that way you'll get a detailed explanation about detected memory leaks - if there are any.
However, the fact that memory_get_usage() returns a constant value looks weird. Can you reduce the problem to a single script? (Or show your script?) Can you nail it down to certain PHP extension? Which version of PHP are you using?

Is there any way to instruct php CLI NOT to load certain modules without specifying a separate ini file?

Long story short:
We use php for a large number of CLI scripts.
When we do a pmap dump of a cli process, we noticed that php CLI is loading certain "used in web mode only" exntesions.
For example:
[root#XXXX php.d]# pmap 5956 | grep apc
00007fe5d0356000 132K r-x-- /usr/lib/XXXX/apc.so
00007fe5d0377000 2048K ----- /usr/lib/XXXX/apc.so
00007fe5d0577000 12K rw--- /usr/lib/XXXX/apc.so
[root#XXXX php.d]#
As you can see, pid 5956 is loading apc.so even tho its a CLI based php process.
This is a waste of memory since APC is never used on the CLI end (unless specifically instructed to do so, doesnt apply to us).
There are a few other extensions we only use for "web mode".
Before we go ahead and create, and thus have to maintain 2 seperate php.ini files, we were wondering:
Is there a way to instruct php / php.ini to load certain modules ONLY on non-CLI mode?
Thanks.
Dump for comments below:
[root#XXXX mod_geoip_1.3.5]# pmap 13330 -x | grep apc ; pmap 18151 -x | grep apc
00007f1a883c9000 132 56 0 r-x-- apc.so
00007f1a883ea000 2048 0 0 ----- apc.so
00007f1a885ea000 12 12 12 rw--- apc.so
00007f7404573000 132 56 0 r-x-- apc.so
00007f7404594000 2048 0 0 ----- apc.so
00007f7404794000 12 12 12 rw--- apc.so
[root#XXXX mod_geoip_1.3.5]# man pmap
Dump for 2 processes, both cron jobs and thus cli based php processes.
If the memory address is different, I am assuming the space used by them is not shared?
runs man php
reads
Create php-cli.ini which excludes the ones you don't want.

Categories