Ruby on Rails

Hi all,

We use ruby 2.0.0 and rails 3.2.19 in production, with OOBGC.  We are having problems understanding why our unicorn workers grow from around 400MB to 8-900MB in a number of hours after a deploy.  We use New Relic and memory_tracker, but 

We see that every so often, the memory_tracker log outputs lines with *** such as:

02-03 06:34:38 pid:17885 rss=320.28 vsize=649.02 *** {:total_allocated_object=>169444, :count=>0, :rss=>12.775423999999987, :heap_used=>2597, :in_use=>866139} /iphone_data/get_article

We aren't quite sure when memory_tracker chooses to print these lines, but they seem important.  I think we can define them as showing the more problematic actions, that grow the heap the most.  Here's an example output of processing the  log, showing the number of times a given action triggers these *** lines over a day:

$ zgrep total_allocated_object log/memtracker_urls.log-20150203.gz|awk '{print $12}'|sed -r 's/[0-9]+(-[^/]+)?/:id/g'|sort|uniq -c|sort -n|tail -n20

     20 /webapp/article/:id
     22 /iphone_data/notification
     24 /users/ajax_get_user_details_card
     26 /articles/get_ajax_alternatives_by_symbol
     28 /account/portfolio/holdings
     31 /iphone_data/sync_portfolios
     32 /account/ajax_authors_portfolio
     34 /iphone_data/get_bookmarks
     35 /news/:id
     46 /user_comments_tracking/ajax_create_notification_cookies
     47 /memcached:id/article_bottom/:id
     57 /etf_hub
     63 /account/portfolio/day_watch
     96 /account/portfolio/news
    106 /account/no_cookie_key
    110 /api/v:id/notification_inbox/get_last_notifications
    147 /article/:id
    171 /instablog/:id/:id
    419 /iphone_data/get_data
   2519 /iphone_data/get_article

It is worth pointing out that , but in our sample of problematic (three-star) actions, the ratio (number of times action grows heap and prints *** to memory_tracker / number of times action called) is not much different.  The actions get_article and get_data simply get called far more than other actions.

Are there any practical solutions to better-understanding what makes these actions grow the heap so much, apart from staring at the code?  We feel we lack data / visibility in order to make improvements.  Please let me know if this is too vague, and if more details can help provide better responses from the list.

Antony

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/30e6fe0b-02da-41da-bfca-01c1a6df8c06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.