<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Memory-hungry Ruby daemons</title>
	<atom:link href="http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/</link>
	<description>On Ruby, software and the Internet</description>
	<lastBuildDate>Tue, 03 Jan 2012 09:53:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Eric Hodel</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-752</link>
		<dc:creator>Eric Hodel</dc:creator>
		<pubDate>Tue, 14 Sep 2010 01:00:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-752</guid>
		<description>&quot;MRI never gives back unused memory&quot; is not entirely true.  Ruby will free unused struct heaps_slot when free_unused_heaps() is called at the end of gc_sweep() and after rb_gc_finalize_deferred().

You should be able to see the resident set size go down (RSS) from time to time as well, but this depends in part on how your OS&#039;s malloc(3) is implemented and how lucky you are in your allocation patterns.

Only VALUEs are stored on the ruby&#039;s heap, not the objects themselves [hand wave over Fixnum].  Arrays and Strings are allocated on the C heap [hand wave over 1.9 behavior for small Arrays and Strings].

Here&#039;s a thought experiment:

Some objects are allocated that cause a new struct heaps_slot to be allocated, then a bunch of objects Strings or Arrays are allocated on the C heap.  Memory will look like this:

[old stuff, struct heaps_slot, Array, String, Array]

Then there is a GC pass and one of those items are appended to an object that ends up in an earlier heaps_slot (the object is long lived).  Finally the recently allocated objects and their struct heaps_slot are freed.  Memory will look like this:

[old stuff, free, free, free, Array]

The free space will still count against you in your processes size.  Until the OS swaps out the free pages it may even count against you in RSS.

The problem is that some memory allocation patterns cause fragmentation both in the process address space and the struct heaps_slot address space.</description>
		<content:encoded><![CDATA[<p>&#8220;MRI never gives back unused memory&#8221; is not entirely true.  Ruby will free unused struct heaps_slot when free_unused_heaps() is called at the end of gc_sweep() and after rb_gc_finalize_deferred().</p>
<p>You should be able to see the resident set size go down (RSS) from time to time as well, but this depends in part on how your OS&#8217;s malloc(3) is implemented and how lucky you are in your allocation patterns.</p>
<p>Only VALUEs are stored on the ruby&#8217;s heap, not the objects themselves [hand wave over Fixnum].  Arrays and Strings are allocated on the C heap [hand wave over 1.9 behavior for small Arrays and Strings].</p>
<p>Here&#8217;s a thought experiment:</p>
<p>Some objects are allocated that cause a new struct heaps_slot to be allocated, then a bunch of objects Strings or Arrays are allocated on the C heap.  Memory will look like this:</p>
<p>[old stuff, struct heaps_slot, Array, String, Array]</p>
<p>Then there is a GC pass and one of those items are appended to an object that ends up in an earlier heaps_slot (the object is long lived).  Finally the recently allocated objects and their struct heaps_slot are freed.  Memory will look like this:</p>
<p>[old stuff, free, free, free, Array]</p>
<p>The free space will still count against you in your processes size.  Until the OS swaps out the free pages it may even count against you in RSS.</p>
<p>The problem is that some memory allocation patterns cause fragmentation both in the process address space and the struct heaps_slot address space.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Compilação de pequenas novidades do mundo Ruby - Maio, Junho e Julho de 2009</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-403</link>
		<dc:creator>Compilação de pequenas novidades do mundo Ruby - Maio, Junho e Julho de 2009</dc:creator>
		<pubDate>Sun, 09 Aug 2009 00:34:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-403</guid>
		<description>[...] Mike Perham escreveu o artigo Memory-hungry Ruby daemons (em inglês) que explica como o REE pode ser útil na redução do consumo de memória com daemons [...]</description>
		<content:encoded><![CDATA[<p>[...] Mike Perham escreveu o artigo Memory-hungry Ruby daemons (em inglês) que explica como o REE pode ser útil na redução do consumo de memória com daemons [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Interesting Ruby Tidbits That Don’t Need Separate Posts #25</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-357</link>
		<dc:creator>Interesting Ruby Tidbits That Don’t Need Separate Posts #25</dc:creator>
		<pubDate>Sat, 30 May 2009 00:44:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-357</guid>
		<description>[...] an aside, Mike Perham&#039;s article, Memory-hungry Ruby daemons, demonstrates how REE can prove useful in reducing memory use on long-running [...]</description>
		<content:encoded><![CDATA[<p>[...] an aside, Mike Perham&#8217;s article, Memory-hungry Ruby daemons, demonstrates how REE can prove useful in reducing memory use on long-running [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mperham</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-353</link>
		<dc:creator>mperham</dc:creator>
		<pubDate>Thu, 28 May 2009 19:24:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-353</guid>
		<description>Please also note this issue has nothing to do with Rails in particular.  Any large, long-running Ruby application will have this problem.</description>
		<content:encoded><![CDATA[<p>Please also note this issue has nothing to do with Rails in particular.  Any large, long-running Ruby application will have this problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mperham</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-352</link>
		<dc:creator>mperham</dc:creator>
		<pubDate>Thu, 28 May 2009 19:22:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-352</guid>
		<description>My daemon happens to be an SQS queue processing daemon but has to load much of Rails because it uses ActionMailer.  I&#039;ll probably move to merb-mailer so I can remove ActionPack.</description>
		<content:encoded><![CDATA[<p>My daemon happens to be an SQS queue processing daemon but has to load much of Rails because it uses ActionMailer.  I&#8217;ll probably move to merb-mailer so I can remove ActionPack.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rick</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-351</link>
		<dc:creator>rick</dc:creator>
		<pubDate>Thu, 28 May 2009 19:14:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-351</guid>
		<description>Oh I got the impression that he was speaking about the application processes, which probably DO require ActionPack.  Matt: sounds like you&#039;re talking about long-running ruby job queue processes, which don&#039;t need ActionPack</description>
		<content:encoded><![CDATA[<p>Oh I got the impression that he was speaking about the application processes, which probably DO require ActionPack.  Matt: sounds like you&#8217;re talking about long-running ruby job queue processes, which don&#8217;t need ActionPack</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Todd</title>
		<link>http://www.mikeperham.com/2009/05/25/memory-hungry-ruby-daemons/comment-page-1/#comment-346</link>
		<dc:creator>Matt Todd</dc:creator>
		<pubDate>Tue, 26 May 2009 03:27:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.mikeperham.com/?p=271#comment-346</guid>
		<description>You could also require less of Rails by just including the absolute minimum (ActiveRecord/ActiveResource and ActiveSupport in most cases) if you&#039;re not already, which would save some space. You normally don&#039;t need to include what&#039;s in ActionController et al.</description>
		<content:encoded><![CDATA[<p>You could also require less of Rails by just including the absolute minimum (ActiveRecord/ActiveResource and ActiveSupport in most cases) if you&#8217;re not already, which would save some space. You normally don&#8217;t need to include what&#8217;s in ActionController et al.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

