Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>ActiveRecord is fairly memory-hungry - be very careful when doing selects, and be mindful that Ruby automatically returns the last statement in a block as the return value, potentially meaning that you're passing back an array of records that get saved as a result somewhere and thus aren't eligible for GC.</p> <p>Additionally, when you call "Post.not_expired.each", you're loading <em>all</em> your not_expired posts into RAM. A better solution is find_in_batches, which specifically only loads X records into RAM at a time.</p> <p>Fixing it could be something as simple as:</p> <pre><code>def do_analytics Post.not_expired.find_in_batches(:batch_size =&gt; 100) do |batch| batch.each do |post| if post.analytics_eligible? #this method is never called Post.find_for_analytics_update(post.id).update_analytics end end end GC.start end do_analytics </code></pre> <p>A few things are happening here. First, the whole thing is scoped in a function to prevent variable collisions from holding onto references from the block iterators. Next, find_in_batches retrieves <code>batch_size</code> objects from the DB at a time, and as long as you aren't building references to them, become eligible for garbage collection after each iteration runs, which will keep total memory usage down. Finally, we call <code>GC.start</code> at the end of the method; this forces the GC to start a sweep (which you wouldn't want to do in a realtime app, but since this is a background job, it's okay if it takes an extra 300ms to run). It also has the very distinct benefit if returning <code>nil</code>, which means that the result of the method is <code>nil</code>, which means we can't accidentally hang on to AR instances returned from the finder.</p> <p>Using something like this should ensure that you don't end up with leaked AR objects, and should vastly improve both performance and memory usage. You'll want to make sure you aren't leaking elsewhere in your app (class variables, globals, and class references are the worst offenders), but I suspect that this'll solve your problem.</p> <p>All that said, this is a cron problem (periodic recurring work), rather than a DJ problem, in my opinion. You can have a one-shot analytics parser that runs your analytics every X minutes with <code>script/runner</code>, invoked by cron, which very neatly cleans up any potential memory leaks or misuses per-run (since the whole process terminates at the end)</p>
    singulars
    1. This table or related slice is empty.
    1. POrails high memory usage
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USChris Heald
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POrails high memory usage
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThe only thing I would add to this excellent answer is a note that any Rails process will consume quite a lot of memory - your 110mb is not uncommon. This isn't indicative of a memory leak in your code, or how much processing you've done. Processing 1000 records or 10M records will use the same amount of memory if you've done things properly (the way Chris has explained).
      singulars
      1. PO
      1. USwuputah
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload