Bug #70098 [Asn]: Real memory usage doesn't decrease

Edit report at https://bugs.php.net/bug.php?id=70098&edit=1 ID: 70098 Updated by: laruence@php.net 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: 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.. Previous Comments: ------------------------------------------------------------------------ [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... ------------------------------------------------------------------------ [2015-07-20 11:47:24] bwoebi@php.net The memory is never released back to the system. That may go bad with a few long running worker processes doing complicated calculations with a lot of data. They'll eat all the memory and system will need to swap (or slow down in other ways…). Hence I think we should care. ------------------------------------------------------------------------ [2015-07-20 06:12:36] laruence@php.net why we need them ? this is just a particular case that triggers allocates lot's of size type.. and it won't affacts memory_get_usage(false)... ------------------------------------------------------------------------ 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