[EDIT by danbrown AT php DOT net: This is intended by the author to only be used with PHP 4 < 4.3.2.]

I'd just like to point out that although sandeepc at myrealbox dot com's idea for displaying the current memory usage is a good one, it's perhaps a bad idea to pipe the entire process list through grep. A better performing method would be to select only the process we're interested in:

At first glance this may sound like "What the hell? Everybody knows, that we mean 1024 not 1000 and the difference is not too big, so what?". But in about 10 years, the size of harddisks (and files on them) reaches the petabyte-limit and then the difference between PB and PiB is magnificent.

Sometimes, we need all memory to run our task, we do ini_set('memory_limit', -1 ), or maximum value we have.

To avoid stuck of server on long and memory consuming tasks, i wrote this check. This is not the same as memory_get_usage() do, but more. It shows virtual memory amount, taken by your process. In percents.

If nothing else in the user notes below works for you, you can get a very (VERY) rough estimate of PHP memory usage by outputting the $GLOBALS array, stripping it of indentation whitespace, and counting the characters in the resulting string. This method has a very high overhead (to be expected), but works on all operating systems, regardless of whether or not they have the --enable-memory-limit config option set. I find that the syntax overhead of the print_r() statement roughly accounts for the PHP runtime base memory usage.

The code below is set up to work on all arrays, not just the $GLOBALS array. Keep in mind that outside data referenced by resource IDs, such as database results and open file data, is not included in this total.

I can confirm that this function triggers a garbage collection. I have a script that exceeded 128MB of memory at some point and ended with a fatal error. I was confused, because the script dealt with some large files initially, but the memory load from that point on should have been marginal, and the error occurred at the very end.

Those large files were dealt in a dedicated function and i even used unset() on the variable holding the file after the file was written to disk inside that function. So the memory should have been cleared twice, first after the unset() call, and second once the function ended.

To debug the memory usage, I called memory_get_usage(true) at some points and echo-ed the memory allocation. Just by adding a few echos here and there in the script, the memory usage never exceeded 1MB overhead (on top of the current file size) and the memory error disappeared.

not sure how this works internally but I have observed sort of side effects here: calling this function apparently triggers PHP's "garbage collector" -- and frees some memory. I managed to "fix" some savagely coded mess of a web application solely by calling this function just before the code that would usually throw out-of-memory errors. the php version there was 5.2.10