ara.t.howard / noaa.gov wrote:
> i don't think you have a leak.  try running under electric fence (ef).  
> when i
> do i clearly see the memory rise from 1->20% on my desktop, and then 
> decline
> back down to 1%, over and over with no reported leaks.  the cycle matches
> the logging of the script perfectly.
> 
> here's the thing though, when i don't run it under electric fence i see the
> memory climb to about 20% and then stay there forever.  but this too 
> does not
> indicate a leak.  it just shows how calling 'free' in a process doesn't 
> really
> release memory to the os, only to the process itself.  the reason you 
> see the
> memory vary nicely under ef is that it replaces the standard malloc/free 
> with
> it's own voodoo - details of which i do not understand or care too.  the
> point, however, is that it's 'free' which is doing the 'leaking' - just 
> at the
> os level, not the process (ruby) level.  we have tons of really long 
> running
> processes that exhibit the exact same behaviour - basically the memory 
> image
> will climb to maximum and stay there.  oddly, however, when you tally 
> them all
> up the usage exceeds the system capacity plus swap by miles.

So, to test this hypothesis, the OP could try to instantiate a large 
number of objects, and see if there is no effect on the vmsize reported 
by the OS, right? Because those objects should be able to use the memory 
that is owned by the process, but not used by ruby objects.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407