Hello. >The first thing I'd like you to try is to change the following line in >zend_alloc.c >zend_mm_startup(&AG(mm_heap), 256*1024); >to >zend_mm_startup(&AG(mm_heap), 32*1024); // You can also try 16 > >I didn't change this in the CVS yet because libXML2 2.5.9 (or was it >2.5.8?) has a bug (memory corruption) which indirectly would cause a crash. >Best is if you upgrade to 2.5.10 and then changing this value shouldn't >cause any problems. I will try this and post the results tomorrows. I think it will improve things a little but will not solve the problem itself, which is that the memory cache in zend_alloc.c stops the zend_mm.c heap manager from recombining the small free blocks into bigger free blocks.
>Secondly, right now except for the exact match strategy for small blocks, I >am using a best match strategy. I guess I could still change the insertion >order (complicating implementation a tiny bit) but do you think it would >really be useful? As I'm using best fit most likely the age of the block >won't make much difference. Yes, but really big blocks like the newly allocated segments all go to bucket 0, and best fit does not work for non-standard memory blocks in bucket 0, so every attempt to allocate a non-standard block will immediately fragment the newly allocated segment. When debugging the problem I made a simpe patch that will periodically dump the memory map the way zend_mm.c sees it, so it really looks to me that the memory cache is causing more damage than help. >Last but not least, in the past I did discover that ZEND_MM performed >better without the fast memory cache in zend_alloc.c That's why there's a >define there which theoretically turns it off with ZEND_MM. I have already tried turning this off when looking why my RAM usage increases all the time. It really improves things and I have posted a patch in a separate message. THe tests are performed on Linux. vesselin ----------------------------------------------------------------- http://club.ABV.bg - Клуб АБВ - Винаги ON ! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
