Musings of a Trained Monkey: Tag typo

RubyGems memory reduction...

Steve Longdo — Sat, 12 Aug 2006 07:00:00 +0000

I did gain some insight into the number of Gem::GemPathSearcher instances through my efforts. They correspond nicely for each piece of Rails that is loaded; ActionMailer, ActiveSupport, ActiveRecord, ActionPack, ActionWebService and Railties. Each of these has the require 'rubygems' statement in it. I believe this is why I was seeing multiple instances of Gem::GemPathSearcher.

As explained before instances of these take up an amount of memory proportional to the number of gems/gem versions in a repository. Making Gem::GemPathSearcher a Singleton of course, resolves more than one instance being loaded into memory. This has been submitted as a patch to RubyGems [ticket #5394].

Installing a patched version of RubyGems 0.9.0 on TextDrive to demonstrate the fix with Typo proved to be the most frustrating part. I will write a follow up posting on exactly how to do this in the near future. Hopefully they will release an updated RubyGems soon!

Shared hosts will definitely want to patch their RubyGems installs to reduce their memory consumption across all of their Rails users. TextDrive in particular should buy me a present or something :-)

I've learned a great deal about the Ruby memory ecosystem by digging into this issue with RubyGems. I got help from some folks on the Rails mailing list but far and away I want to thank Stef Telford for the help. Mad props to you for putting up with all of my questions and ramblings!

Finally some numbers:
Gem::Dependency x330(57415)
Gem::Version::Requirement x693(61939)
Gem::SourceIndex x1(1632488)
Gem::GemPathSearcher2 x1(1647806) <-- Gem::GemPathSearcher x5(7901012)
Hash x1219(1789928)
Gem::Specification x362(1795089)
String x113992(3876455)
Array x7415(5080185)
TOTAL == 16967273 <-- TOTAL == 28496875

Update: These memory numbers are lower than actual process size. They vary by number of Modules loaded as well as Objects counts. Not all Objects and Modules can be evaluated for memory size. The new routing code in the latest version of Rails may also account for some of the difference as well. So grain of salt...

RubyGems: Single/Multi-tons and memorysize

Steve Longdo — Wed, 09 Aug 2006 03:41:00 +0000

There is a line in the RubyGems source code, @gempath_searcher ||= Gem::GemPathSearcher.new, from custom_require.rb that seeks to make Gem::GemPathSearcher a Singleton class. For some reason this isn't sufficient as I have seen as many as five instances of it existing in the same thread during profiling of Typo. I am not sure why more than one gets generated. It may relate to Rails aliasing the Kernel.require method after RubyGems has in custom_require.rb.

Review of the source makes me understand why a Gem::GemPathSearcher instance can be so large, it holds the gem specifications for every gem and version on the load path. Running locally this is not a big deal, as you probably don't have a lot of gems and their versions installed. On a shared host though there are tons of gems and versions of gems installed (350+ on my TextDrive server!).

A permanent solution to fix Gem::GemPathSearcher to truly be a Singleton class would probably be something as simple as checking Object.const_defined?(:GemPathSearcher) to see if the class is already in memory.

A quick alternative would be restricting the gem library path to a gem repository other than the shared host's repository. This can be done by exporting the GEM_HOME variable in your shell. There is also a GEM_PATH variable that can be used to support multiple repositories. Examples of how to work with these variables can be found on the Rails wiki. It should be possible to make a repository containing just the gems your app needs and nothing else. This will reduce the memory footprint of Gem::GemPathSearcher quite a bit, no matter how many instances of them there might be!

Obviously I am still learning the implications of RubyGems working together with Rails apps. I apologize for you the reader being dragged along on my quest to learn. Anyone wishing to bring this quest to a quick end just tell me how it ends.

Update: I will continue my research until we arrive at the truth. I still have some other RubyGems optimizing techniques to apply. My hope is using something like the gemconfigure file described in the documentation will be the difference between the Whole Milk Memory and Skim Milk Memory. Also I will reformat the code in the post to be pretty tomorrow. need to add some stuff to scribbish to accomplish this and I want to go to bed now...

RubyGems dependency management and memory use...

Steve Longdo — Tue, 08 Aug 2006 06:30:00 +0000

I've been looking into the nebulous matter of Rails memory management lately, using Typo4 as my model app. In my research thus far I have noticed that several of the highest memory using items are from the RubyGems library. Particularly the Gem::GemPathSearcher object. After running a few days I have picked up five instances of it taking up nearly 8MB of RAM which is odd because the first time I profiled it there were only four of them. I am not sure why RubyGems needs to be in memory after the app initially loads, especially the ~1.5MB SourceIndex and the 352 Gem::Specification objects for another ~1.6MB. Seems like wiring of any dependencies could be done once at start up. I am not sure if this relates specifically to how Typo uses RubyGems or if all Rails apps incur the memory overhead penalty for RubyGems. If any one with knoweldge of the internal functioning of RubyGems would take the time to educate me on this it would be much appreciated. Also if someone could explain why RubyGems pops up at all since all Typo dependencies are deployed into the vendor folder.

Another one to watch is the slow accumulation of ActiveRecord::ConnectionAdpaters::MysqlColumn, up to 217 instances in memory. Not a particularly large memory hit, but they have steadily grown in number over the last few days. i may swith over to my Postgres database and see if the same thing happens with its connecton adapter.

Finally the allocation of Array objects is interesting. The number of instances in use has gone down by roughly -2000 instances but the memory use of the remaining Arrays has gone up by about 2MB. I need to explode these Arrays and see what they hold and why they stick around so long. Partial output of profiling included below:

Class x852(21194)
Gem::Version x709(24981)
ActiveRecord::ConnectionAdapters::MysqlColumn x217(35410)
Regexp x1343(52312)
Gem::Dependency x309(53743)
Gem::Version::Requirement x662(59168)
Gem::SourceIndex x1(1563056)
Gem::Specification x352(1714117)
Hash x1257(1858255)
String x117204(3869923)
Gem::GemPathSearcher x5(7901012)
Array x6093(11102839)
TOTAL == 28496875

Please do share your experiences with Rails or RubyGems memory use in the comments.

Typo 4.0 and memory reduction...

Steve Longdo — Fri, 04 Aug 2006 22:56:00 +0000

Have you upgraded to the latest Typo release only to find that it hits the per process memory limit on your host? It happened to me.

Here is how I went about reducing the memory footprint of Typo:

Removed sidbars that aren't used from the installation.

Amazon through XBox.

Removed unused requires from environment.rb

In particlular aggregation classes for the Sidebars that were removed.

Make sure to not load any unnecessary parts of Rails (i.e. ActiveWebService) That's right I use the admin screen to post!
Most importantly deleted the sparklines_textfilter.

That last one makes a huge difference in the memory use of Typo. It removes the need to load RMagick saving around ~8MB from your process size. In fact these changes have brought Typo down to about 33MB in memory. Since the average Rails app uses 30MB this isn't too bad, however memory consumption slowly creeps up over a period of days and hits the limit. Seemingly a memory leak. I will be digging into this issue as time allows, but work is keeping me busy.

I will eventually be using a diferent theme but I switched to this one while checking out memory use and haven't spent enough time on my new one yet.

Mephisto...

Steve Longdo — Tue, 20 Jun 2006 04:00:00 +0000

I've been learning the ins and outs of working with Rick Olson's new Blogging/CMS Lite project, Mephisto. I've been impressed so far. Feature wise it offers a lot for as small as the code base is.

Using Liquid templates instead of rhtml is taking some getting used to. I have a close port of this Typo blog running on my laptop. I am still ironing out some kinks with interpretation of <pre> and <code> tags between Typo and Mephisto. Mainly my older posts with code included have issues. I do miss some of the sidebar functionality and I will be taking a look at adding a "feedparser section" to be able to recreate some of the sidebars in Mephisto.

Rick and company seem to have implemented caching the right way, everything just works and is fast! I can definitely see why the Rails blog decided to make the switch.

Lightbox V2 integration with Typo...

Steve Longdo — Tue, 23 May 2006 11:31:00 +0000

It was brought to my attention that I didn't post a lot of detail about integrating Typo with Version 2 of lightbox. I'll attempt to correct that with a quick write up.

Start by downloading the most recent lightbox release. From here we will want to copy the images that are distributed with it into our Typo installation's public/images folder.

Next up is the javascript file and the stylesheet. I have made some slight modifications to the originals to make the image paths non-relative and the additon of links that show in the caption portion of the light box. Grab the following javascript file and put it in your public/javascripts directory. Then get the css file and put it in your public/stylesheets directory.

Final step for usage is to place a couple of lines in your active theme's layout/default.rhtml. Under the <%= page_header %> line place the following two lines:

<%= javascript_include_tag "lightbox-modded"  %>
<%= stylesheet_link_tag "/stylesheets/lightbox" %>

This should get you up and running with lone imgs
<img src="..." rel="lightbox"/>
and/or groups of imgs
<img src="..." rel="lightbox[groupName]"/>
<img src="..." rel="lightbox[groupName]"/>

Lightbox V2 and the flickr sidebar...

Steve Longdo — Tue, 23 May 2006 06:57:00 +0000

So to grant the flickr sidebar access to the powers of the lightbox script is a fairly simple trick, in your theme's views/plugins/sidebars/flickr/content.rhtml file (you can make this path and the file if it is not present in your particular theme.)


<% if @flickr -%>
<h3><%= @flickr.title  %> (<%= link_to "flickr", @flickr.link %>)</h3>

<div id="flickr">
<% for pic in @flickr.choose(count.to_i) -%>
  <div class="flickr<%= format%>">

<%= case format
          when 'square':
            link_to image_tag(pic.square, :alt => pic.title),
              pic.image.gsub!(/_m/,''),
              { :rel => 'lightbox[flickr]',:alt => pic.title, :title => pic.title }
          when 'rectangle':
            link_to image_tag(pic.thumb, :alt => pic.title),
              pic.image.gsub!(/_m/,''),
              { :rel => 'lightbox[flickr]',:alt => pic.title, :title => pic.title }
          end

 %>
</div>
  <% end -%>
</div>
<% end -%>

When XML is binary you have a XMLHttpRequest problem...

Steve Longdo — Wed, 19 Apr 2006 23:55:00 +0000

Lesson learned the hard way on this one. I have been working with the FCKEditor and getting a strange error specifically:

Error: this.DOMDocument has no properties
Source: /javascripts/fckeditor_gecko_2.js
Line: 22

After pounding my head into my laptop for awhile and putting some whitespace into that file I figured out that I was getting a null response from the XMLHttpRequest for the fckstyles.xml file.

I tried loading it directly from the browser and was promped to save the file to disk. Normally it would open in the browser. Why would it think the XML file is binary? The xml mime-type mapping was removed from the Typo lighttpd.conf file. File this one under "want to know how to keep an idiot busy for hours"... *sigh*
Make sure that your lighttpd.conf has a mapping for XML if you are doing anything with XML.

mimetype.assign = (  
  ...
  ".txt"        =>  "text/plain",
  ".xml"        =>  "text/xml"
)

Search nearly working...

Steve Longdo — Thu, 13 Apr 2006 23:39:00 +0000

I nearly have the search working the way I want. The word count it generates is based on words only. HTML is stripped as is any content between <code> tags. I notice that the current live search in Typo looks at the html content when making a match. So if you see any articles coming back with an empty Snippet block("") it is because your search matched something in a generated URL and no actual words in the article.
I am working on the best way to handle this behaviour. Maybe just list the links that appear in the article or provide a count of them.
Also I will be making hyperlinks in the balloons functional. I created new graphics for the balloon to see if IE will correctly display the new GIF (I knew PNG support in IE was bad, but this was my first personal encounter), I will know in a little bit when I get to work and can check it out in IE...
By the way the concept for this method of displaying search results is all Dunstan Orchard. I've just been making it work within Typo.

Site update...

Steve Longdo — Mon, 10 Apr 2006 16:40:00 +0000

I updated my theme a bit, this one is either going to be called "Civil War" or "Feeling Blue". It is still in progress, however, so you may observe some more changes over the next few days. The Search is back and I modified the lightbox javascript a little bit too. I have a couple new sidebars in the works. Now running Rails 1.1 and a newer version of Typo modified to use less memory.