"M. Edward (Ed) Borasky" <znmeb / cesmail.net> writes:

> Yohanes Santoso wrote:
>> "ara.t.howard" <ara.t.howard / gmail.com> writes:
>>
>>> On Oct 11, 2007, at 6:40 AM, Yohanes Santoso wrote:
>>>
>>>> But most importantly, one should know that RSS and VSZ are not
>>>> Accurate Measure of Memory Usage.
>>>>
>>>> YS.
>>> sorry, for jumping in, but i'd love your opinion on this yohanes:
>>>
>>>   http://drawohara.tumblr.com/post/14421265
>>
>> Ah, I'm sorry. I have been swamped recently and has not been able to
>> read this mailbox.
>>
>> Too bad you're on Darwin. Had you been on Linux (and on glibc), I'd
>> suggest you to patch ruby so that it executes this first thing after
>> it starts:
>>
>>   mallopt(M_MMAP_THRESHOLD, 0); /* declared in malloc.h */
>>
>> What this does is to make all allocation using mmap instead of
>> sbrk. This allows all free() to return the allocated space back to the
>> kernel. Doing this eliminates the possiblity that VSZ climbs because
>> of memory fragmentation. If VSZ still climbs, then there are some
>> garbage somewhere not released. OTOH, this causes syscall for every
>> allocation.
>>
>> I hope there is a suitable equivalent in Darwin.
>>
>> YS.
>
> Is this worth making part of the standard Ruby build on Linux?

Definitely not. This is just for diagnostic. It's also quite expensive
because you incur syscall for each memory allocation&deallocation.

If VSZ climbs up because of memory fragmentation, then it is really a
perception problem. No unnecessary real memory will be wasted because
of the process memory management the kernel does. The only real
annoyance is when the process terminates, the kernel will be swapping
in all those pages. This is an annoyance that could borderline to
become a problem depending on your requirement. Some OSes, like
FreeBSD, has a special option that disable the swapping in of all
those pages when a process terminates[1].

If VSZ climbs up because garbages are not being collected, then you
can try to fix the problem. Most probably they are fixable from user
code (having references to unnecessary objects). If the problem is
because of ruby's GC quirknesses (few but could be very difficult to
fix), then it's a toss-up. But I still say the cost is probably not
worth it.

I don't favour the long-running process model for server. I prefer to
fork() for each request. So I'm rarely bothered by whatever ruby's GC
quirknesses that I may have triggered. I understand that this approach
is not trendy anymore and RoR does not support this model, but I'm
just throwing it out in the open for an alternative work-around where
possible.


YS.






Footnotes: 
[1]  Thanks to Daniel DeLorme for the link: http://web.archive.org/web/20061023143846/www.crowdedweb.com/articles/2006/03/22/ruby-on-rails-and-application-memory-consumption-patterns