We needed to locate where most of the memory is allocated in our scripts (as some of them became too memory hungry), so I've created
memtrack extension.
This extension helps us to see unusually big memory allocations in production code.
Of course we use error logging, so memtrack just produces warnings like this one:
Warning: [memtrack] [pid 26177] user function foo() executed in /tmp/1.php on line 7 allocated 4194304 bytes
[memtrack] is a prefix for all warnings produced by the extension, so that one could find them in the logs.
[pid 26177] is, well, a PID, so that one could follow a certain process (if needed).
user function means it's a user defined function; the ones provided by PHP or one of its extension are reported as
internal functions.
Memtrack supports the following INI options at the moment:
- memtrack.enabled - Boolean flag, which enables or disabled the extension. Default value is 0, i.e. disabled.
- memtrack.soft_limit - "Soft" memory limit. It means that a certain function cannot increase memory usage by more than X bytes and a warning is produced when the limit is exceeded, if the function is not ignored. Default value is 0.
- memtrack.hard_limit - "Hard" memory limit. A warning is produced when the limit is exceeded, whether or not the function is listed in memtrack.ignore_functions. Default value is 0.
- memtrack.ignore_functions - A comma- or whitespace-separated list of functions, which are to be ignored. The values are case-insensitive, for class methods use Class::method syntax. Empty by default.
- memtrack.vm_limit - Virtual memory size limit (set on a process), measured on shutdown only, might be helpful if you suspect a process is "leaking" memory. A warning is produced when the limit is reached. This option is currently available only on Linux (if you know how to get virtual memory size of the current process on any other system - please let me know). Default value is 0.
The extension checks memory usage changes per op_array, which in most cases means a function call or an included file with flat code, so you should not notice any performance loss.
memtrack is still BETA, so let me know if you find any problems there, or if you have any suggestions on how to improve it.
Pierre is working on Win32 build just as I write this, so Win32 dlls should be available soon, stay tuned.
/root/src/php/memtrack-0.1.0/libtool: line 460: CDPATH: command not found
/root/src/php/memtrack-0.1.0/libtool: line 1152: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.
gmake: *** [memtrack.lo] Error 63
sigh well im certainly interested, now iv just gotta fight libtool
this sounds like an interesting extension. However after
installing it with pecl install memtrack-beta and
adding memtrack.enable = 1 to my php.ini
and restarting apache
I still can't find anything in phpinfo()'s output to confirm it installed successfully. I also set the soft limit to 1024 which should trigger easily with TYPO3, but I can't find anything in the logs.
I'm on Mac OS X with macports, Apache 2.2.11, PHP 5.2.8 running as mod_php
Any feedback is appreciated!
>adding memtrack.enable = 1 to my php.ini
Just memtrack.enableD is not enough, you need to add "extension=memtrack.so" to your php.ini.
And check extension_dir, it should point to the real dir, not ".".
Let me know if it works (or doesn't work) on MacOS, I didn't have a chance to test it there (yet).
I tried it today and it compiles and works fine on MacOS with PHP 5.3.0alpha3.
I'm sure we can put this to some good use...
pecl install memtrack-beta and changes to php.in
extension=memtrack.so
memtrack.enabled=On
but still i face some problem, my apache doesn't start even with configtest "Syntax OK"
then checked concern error logs and encounters
memtrack.so doesn't appear to be a valid Zend extension
please help fruitfully.
em not using zend_extension anywhere for memtrack.so
that's been used for XDEBUG only which works finely.
once i comment "extension=memtrack.co" apache runs properly.
do you suggest what exactly the issue is?
For missing/wrong extension you would see "PHP Warning: PHP Startup: Unable to load dynamic library ..." instead.
But I suppose it doesn't check memory used by mysql results ? (except if mysqlnd is used). We use a specific patch on the mysql extension for this.
Not as long as mysql results use malloc() directly.
php-5.2.6-fpm + nginx, mysql 5.0.51a on Ubuntu 8.04. Just trying to test if memtrack.so works correctry, trying to fire up wordpress. After creating wp-config.php - just got php segfault with index.php.
Jan 30 15:35:17.960800 [WARNING] fpm_children_bury(), line 215: child 14711 (pool default) exited on signal 11 SIGSEGV after 7.189305 seconds from start
$ php -m
[PHP Modules]
ctype
curl
date
dom
eAccelerator
filter
hash
iconv
json
libxml
memtrack
mysql
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
[Zend Modules]
eAccelerator