Z
Zed Shaw
So I recently posted that there's a memory leak in the below script:
http://pastie.caboo.se/10194
With graphs and all. The general response was the following:
1) That's just how the OS accounts for memory (wrong since the processes
were getting killed for using too much ram, and the OS doesn't keep 100m
around over 10 minutes of slow ram cycling).
2) That's fixed in ruby 1.8.5 (wrong again as we tested it in 1.8.5 and
actually had worse results).
3) It must be written wrong (yet not many suggestions on how to rewrite
it).
4) Don't use Mutex.lock/Mutex.unlock but instead use Mutex.synchronize
{ } (wrong, doing this reduced the total ram for some, not for others
and still lead to an overall increasing trend).
Bradley Taylor and I investigated it further today and he found that
Sync does not have this leak. Here's the evidence for it:
http://pastie.caboo.se/10317
As you can see this is nearly the same code but instead of Mutex we use:
@guard.synchronize
EX) {
}
And make @guard a Sync object. From the graph you can see the GC
working *properly*.
I just want to say that this is how ram is supposed to operate with a
GC. If you see memory that increases to a level and doesn't go down
then you've got a leak.
Also, I managed to reduce this bug down to the initial test script in
about an hour. That helped tremendously in finding the problem and the
solution. I suggest everyone take this approach with complex bugs as
well since a simple yet unrealistic case that demonstrates the bug is
easier to deal with.
Hopefully I'll get this change into Mongrel and it'll fix the memory
leak. Thanks for everyone's help and suggestions.
http://pastie.caboo.se/10194
With graphs and all. The general response was the following:
1) That's just how the OS accounts for memory (wrong since the processes
were getting killed for using too much ram, and the OS doesn't keep 100m
around over 10 minutes of slow ram cycling).
2) That's fixed in ruby 1.8.5 (wrong again as we tested it in 1.8.5 and
actually had worse results).
3) It must be written wrong (yet not many suggestions on how to rewrite
it).
4) Don't use Mutex.lock/Mutex.unlock but instead use Mutex.synchronize
{ } (wrong, doing this reduced the total ram for some, not for others
and still lead to an overall increasing trend).
Bradley Taylor and I investigated it further today and he found that
Sync does not have this leak. Here's the evidence for it:
http://pastie.caboo.se/10317
As you can see this is nearly the same code but instead of Mutex we use:
@guard.synchronize
EX) {}
And make @guard a Sync object. From the graph you can see the GC
working *properly*.
I just want to say that this is how ram is supposed to operate with a
GC. If you see memory that increases to a level and doesn't go down
then you've got a leak.
Also, I managed to reduce this bug down to the initial test script in
about an hour. That helped tremendously in finding the problem and the
solution. I suggest everyone take this approach with complex bugs as
well since a simple yet unrealistic case that demonstrates the bug is
easier to deal with.
Hopefully I'll get this change into Mongrel and it'll fix the memory
leak. Thanks for everyone's help and suggestions.