Edit report at https://bugs.php.net/bug.php?id=70098&edit=1
ID: 70098
Comment by: alex at alex-at dot ru
Reported by: robin dot kunde at recoursive dot com
Summary: Real memory usage doesn't decrease
Status: Assigned
Type: Bug
Package: Performance problem
Operating System: Ubuntu 15.04, OSX 10.10.4
PHP Version: 7.0.0beta1
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
Not only on OOM probably, but on forced gc_collect_cycles() call as well, to make forced cleaning
possible for long running scripts.
Previous Comments:
------------------------------------------------------------------------
[2015-07-21 15:02:13] rasmus@php.net
I think the idea of freeing these on an OOM is a good one. I would hate to see additional overhead
added to try to keep track of these for the common case of short-lived requests.
------------------------------------------------------------------------
[2015-07-21 03:19:17] laruence@php.net
pages are allocated together in trunk(~2M), which means if a page is not used anymore it won't
be able to release back to OS , unless the whole trunk is not used anymore..
------------------------------------------------------------------------
[2015-07-20 19:36:20] bwoebi@php.net
@laruence: That's right. But not the issue. Issue is rather that, having allocated a lot of
pages (e.g. during initialization) and then the variables all normally dtor'ed, the pages will
never be returned back to the OS for the whole lifetime of the script (which may be very long)...
Sure, it's rather an edge-case case, but I'd like to see completely unused pages released
back to the system
But it might involve a per-page counter and steal like a four instructions and a branch per
alloc/free⦠Not sure how much we can afford.
------------------------------------------------------------------------
[2015-07-20 13:28:32] robin dot kunde at recoursive dot com
Base on what you said, I performed another test:
I set memory_limit to 512M. At the end of the script I posted, after nulling out all the vars, and
memory usage being (Real: 422.00, Malloc: 0.36), I tried to read a 200M file. This triggered the
memory exhaustion fatal error. If I read the large file at the beginning of the script, and then
null the var, the script runs as expected and memory usage doesn't change much since it's
a large allocation.
I'm glad that the small bucket pool is counted against the memory limit and scripts can't
accidentally use up to twice as much memory. However, it does make the behavior of long running,
memory intensive script potentially unpredictable.
I understand the performance implications of not having to free those buckets. As a compromise, the
small bucket pool could be cleaned only when absolutely necessary.
------------------------------------------------------------------------
[2015-07-20 13:17:25] laruence@php.net
actually , it won't , let's say you have allocated a 7bytes memory , then one page of 4KB
will allocated for it. and unless there is no any 8 bytes slot in this page, any request for
allocating < 8 bytes won't trigger new memory allocating request to OS...
anyway, maybe we should add some gc of memory if mmap fails of OOM...
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=70098
--
Edit this bug report at https://bugs.php.net/bug.php?id=70098&edit=1