<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="/stylesheets/rss.css"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel>
    <title>Segment7: Process Growth with Railsbench's GC patch</title>
    <link>http://blog.segment7.net/articles/2007/04/17/process-growth-with-railsbenchs-gc-patch</link>
    <language>en-us</language>
    <ttl>40</ttl>
    <description>The Blog</description>
    <item>
      <title>Process Growth with Railsbench's GC patch</title>
      <description>&lt;p&gt;My friend Kevin Watt who runs &lt;a href="http://allpoetry.com/"&gt;Allpoetry&lt;/a&gt; had me help him diagnose problems with memory consumption on his Rails application.  He was seeing processes suddenly jump in size by 46MB, when the processes were already over 100MB to begin with.  After instrumenting to locate the growth in one innocuous method we went through his patches to Rails.

&lt;p&gt;One of the patches Kevin was using was the &lt;a href="http://railsbench.rubyforge.org/"&gt;Railsbench&lt;/a&gt; GC patch.  It turns out that this patch has some very useful instrumenting of its own, so I had Kevin call &lt;code&gt;GC.dump&lt;/code&gt; in that method, and he got the following values:

&lt;pre&gt;&lt;samp&gt;HEAP[ 0]: size= 650000
HEAP[ 1]: size=1170001&lt;/samp&gt;&lt;/pre&gt;

&lt;p&gt;This means there are slots for 1820001 objects in his process.  If you end up creating that many objects Ruby will create a new chunk of object slots by multiplying the previous allocation by 1.8 and adding 1.

&lt;p&gt;The next set of slots would contain slots for 2106002 objects.  Each slot takes up 20 bytes of memory, so roughly 40MB of memory would be used.  Kevin ended up pulling the patch and now has his processes holding on to around 70MB RSS each, rather than 100 or more.

&lt;p&gt;The Railsbench page contains this note about memory consumption alongside the GC patch:

&lt;blockquote cite="http://railsbench.rubyforge.org/"&gt;&lt;p&gt;In addition, a patch for the ruby garbage collector is provided, which can be used to reduce the amount of time spent doing garbage collection, trading memory for speed, as usual (see file GCPATCH for details).&lt;/blockquote&gt;

&lt;p&gt;The initial size of the slots can be tuned, but we neglected to explore that option.  In large-memory situations the patch's behavior is too negative.  Be sure to follow the instructions to the GCPATCH file to get proper operation.  Also, monitor your application's memory usage as the patch may cause your machine to use swap when too many objects are being used or if you've tuned improperly.
</description>
      <pubDate>Tue, 17 Apr 2007 12:57:00 -0700</pubDate>
      <guid isPermaLink="false">urn:uuid:71346cba-3050-4ce6-a2a0-e50ee463cafb</guid>
      <author>drbrain@segment7.net (Eric Hodel)</author>
      <link>http://blog.segment7.net/articles/2007/04/17/process-growth-with-railsbenchs-gc-patch</link>
      <category>Hacking</category>
      <category>Rails</category>
      <category>Ruby</category>
    </item>
    <item>
      <title>"Process Growth with Railsbench's GC patch" by Eric Hodel</title>
      <description>&lt;p&gt;Just the same, the more you increase the initial heap size, the more likely you are to have extremely negative behavior when you have &amp;#8220;too many&amp;#8221; objects.&lt;/p&gt;</description>
      <pubDate>Mon, 30 Apr 2007 13:45:55 -0700</pubDate>
      <guid isPermaLink="false">urn:uuid:daefa2c7-d142-4795-bb04-000c19c810cd</guid>
      <link>http://blog.segment7.net/articles/2007/04/17/process-growth-with-railsbenchs-gc-patch#comment-700</link>
    </item>
    <item>
      <title>"Process Growth with Railsbench's GC patch" by Stefan Kaes</title>
      <description>&lt;p&gt;The patch doesn&amp;#8217;t change the GC algorithm. If you don&amp;#8217;t set any of the environment variables, you will get exactly the same behavior as with an unpatched Ruby. I&amp;#8217;d suggest to start with a smaller initial heap size, or, even better, use railsbench perf_run_gc with a few benchmarks to find out the heap size you need.&lt;/p&gt;


	&lt;p&gt;The patch doesn&amp;#8217;t cause swapping, choosing  the wrong initial heap size does.&lt;/p&gt;</description>
      <pubDate>Sat, 28 Apr 2007 10:45:12 -0700</pubDate>
      <guid isPermaLink="false">urn:uuid:ae58f9c5-dca3-43cf-890f-8d6a0180ad7b</guid>
      <link>http://blog.segment7.net/articles/2007/04/17/process-growth-with-railsbenchs-gc-patch#comment-698</link>
    </item>
  </channel>
</rss>
