On Thursday, 6 September 2012 at 05:23:03 UTC, Nick Sabalausky
wrote:
On Thu, 06 Sep 2012 00:10:36 +0200
"Eldar Insafutdinov" e.insafutdinov@gmail.com wrote:On Wednesday, 5 September 2012 at 21:34:21 UTC, Nick Sabalausky
wrote:On Wed, 05 Sep 2012 23:22:03 +0200
"Eldar Insafutdinov" e.insafutdinov@gmail.com wrote:Ok, I've done some more tests. This time I was stress
testing the server built with
DFLAGS="-version=VibeIdleCollect" . There was one
invocation of GC.collect() before the benchmark started(the
same one as in my previous post). During the stress test
GC.collect() wasn't called from that handler which is
expected as the server wasn't idling. The memory usage grew
to 380Mb. However when the benchmark finished there was GC
collection invoked, but the memory usage stayed at the same
level. This suggests there is a leak somewhere.Or D's curse of false pointers. Did you compile it as 32-bit
or 64-bit?32bit. Is it worth trying 64 bit?
Yes, particularly to help narrow down the cause:
If the problem persists on 64-bit then it sounds like a possible
memory leak as you suggested. But if the problem is false
pointers,
then it has a high likelihood of going away on 64-bit (since
non-pointer values will be much less likely to match 64-bit
memory
addresses).
I ran the tests on 64bit Linux and got the very same results -
memory usage goes up and up.
I just had a thought - could it be a D runtime issue? Because we
use a closure for handling incoming request, it must allocate
memory. Is there a chance that it's not being properly released?
Another possibility is memory fragmentation because there are so
many alocations of small objects happening on every request. I
wonder if a custom allocator could help here at all.