|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57599 Lots of 40Bytes allocs that dont defrag
Submitted: 2007-03-29 04:56 UTC Modified: 2007-04-03 03:32 UTC
From: steve at tequilasolutions dot com Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 5.2.1 OS: FC4
Private report: No CVE-ID: None
 [2007-03-29 04:56 UTC] steve at tequilasolutions dot com
One for Gopal this perhaps as he fixed an earlier bug.

The initial release of 3.0.13 led to quick fragmentation with loads of 16B entries.   A fix involving some byte aligning in sma_alloc reduced this however now over several hours you get left with lots of 40B entries instead which eventually cause the cache to fill up.

Reproduce code:

Expected result:
Some sort of defrag going on.

Actual result:
Frags build and the cache fills.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-03-30 15:02 UTC] gopalv82 at yahoo dot com
I debugged this one to bits, but couldn't find exactly any problem in the code. But a fair bit of testing showed up some interesting statistics on allocations.

So memory sizes which don't lend itself well to splitting (i.e 2*block_size + alignword(1)) turn up as fragments much more easily. 

Maybe a special case to handle those ? I'm sort of poking around for a good solution.

Still not sure how to fix the excessive fragmentation.
 [2007-03-30 15:24 UTC]
I poked the allocation distribution a while ago as well.  And I went back and forth on padding all allocs up to a certain size to avoid small chunks.  Things have shuffled a bit now and based on the current alloc distribution profile, it looks to me like all allocs should be in multiples of 24-byte chunks.  And yes, this does mean higher memory usage since there will be more padding on average, but we will have more uniform and useful fragments to work with.
 [2007-03-31 19:13 UTC] gopalv82 at yahoo dot com
Here's a patch which minimizes fragmentation (again)

It only consumes extra memory if your memory is already fragmented, which is better than padding up everything to multiples of 24 and stuff.

Test and confirm, please.
 [2007-04-01 18:41 UTC] steve at tequilasolutions dot com
Sorry not quite sure how to apply the patch, I unwrapped back to the 3.0.13 dist and then did....

[root@web01 APC-3.0.13]# patch < apc-fraglimit.patch
patching file apc_sma.c
Hunk #3 FAILED at 131.
Hunk #4 FAILED at 162.
Hunk #5 succeeded at 191 (offset -1 lines).
Hunk #7 succeeded at 241 (offset -1 lines).
Hunk #9 succeeded at 509 (offset -1 lines).
2 out of 9 hunks FAILED -- saving rejects to file apc_sma.c.rej
 [2007-04-01 18:44 UTC]
It's against current CVS HEAD.

cvs login
password: phpfi
cvs co pecl/apc

Then apply the patch in the pecl/apc directory
 [2007-04-01 19:05 UTC] steve at tequilasolutions dot com
OK - rebuilt and installed against CVS head, lets see what happens.....
 [2007-04-01 19:13 UTC] steve at tequilasolutions dot com
Looks good so far get the champagne/cider ready...
 [2007-04-02 04:47 UTC] steve at tequilasolutions dot com
Been running for 7 hours now with 28000 user entries, hardly any frags - looks really good.
 [2007-04-02 04:48 UTC] gopalv82 at yahoo dot com
Any memory usage differences ? (% of used and stuff ?)
 [2007-04-02 05:04 UTC] steve at tequilasolutions dot com
hard to tell as there's thousands of entries but I think it used to manage about 30000 + opcode cache in 128Mb so it looks about the same
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed May 29 18:01:34 2024 UTC